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Introduction to the Eleventh Edition 


Welcome to the eleventh edition of PMP® Exam Prep. We can't believe that it has been 25 years since 
Rita published the first edition of this book. RMC has come far since the publication of the first edition in 
1998, as has the project management profession. 

Back when the first edition was published, most project managers were in the United States. Now 
there are more international project managers than ever before. As a result of this industry growth, RMC s 
best-selling materials are now sold all over the world. 

Project management is also a more complex profession than it used to be. Along with the processes, 
concepts, and methods added within the last few years, there are now just as many adaptive approaches to 
project management as there are predictive. The general methodologies and overall practices of project 
management have changed dramatically, which has increased the size of a project managers toolbox. 

PMI has recently introduced A Guide to Project Management Book of Knowledge (PMBOK* Guide), 
Seventh Edition and the Process Groups: A Practice Guide. There is more to learn today than ever. This 
increased complexity is reflected in the eleventh edition of new book. 

This book is vastly different than our previous editions. It's structure is aligned to the Examination 
Content Outline (ECO). Previous editions of this book were built around knowledge areas. In this edition, 
sections directly relate to the ECO's three domains: People (Domain I), Process (Domain II), and Business 
Environment (Domain III). It is more important than ever to read and understand the ECO because it 
covers the domains and introduces adaptive approaches to project management and the PMP* exam. 

Throughout this book, we will remind you to look at your copy of the ECO, and we provide 
opportunities to use it with some new exercises. 

In this book, we bring together the terminology and concepts used in the ECO, the PMBOK* Guide, 
and the Process Groups: A Practice Guide. We synthesize the concepts in a way that makes it easier to 
understand and prepares you for the exam. 


Rita's Process Chart™ has helped thousands of students comprehend and apply predictive project 
management. It remains in this edition and we also introduce Rita's Agile Process Chart™. We believe this 
chart will also help you prepare for the agile content found on the PMP* exam. 

And, you can still play the Rita's Process Chart™ game and Rita's Agile Process Chart™ game on our 
all-new RMC Resources page. The digital RMC Resources page has additional content for a deeper dive 
into concepts found in the book, a searchable glossary for project management terms, access to more games 
and interactive eLearning modules, as well as a mini version of our Hot Topics book. 

With this edition, you also get access to our new interactive tool, RMC Chapter Quizzes. With more 
than 100 questions, you will be able to test your knowledge and you will get exposure to how the real 
exam looks. 

Finally, we present a case study that will be carried throughout the book. You will be able to apply 
concepts presented in the chapters based on this case study. 

While these are significant changes, important aspects of our book remain the same. First, and most 
importantly, is the conversational tone of the book. The eleventh edition maintains its down-to-earth 
conversational style—explaining things simply and clearly. Students say that when they read this book, it 
feels like Rita is talking to them. In many ways, she still is. 

Another thing that remains the same is our continued commitment to helping our students not only 
pass the exam but also become better project managers. That is what the book, and, in fact, our company, is 
all about. 


As you read this book, know that our plan is not to have you memorize a bunch of rules and formulas 
just to pass the exam and then promptly forget them. For one thing, given the situational nature of most 
questions on the exam, we believe that such an approach would be unsuccessful. For another, it’s not what 
we’re about. This book is not just a prep guide—it’s a learning tool. If you master the contents of our book, 
you will pass the exam, but it’s more than that. After you learn what we have to teach, you’ll be a better 
project manager. At the end of the day, that’s what the world needs. Still, our goal with this book is to get 
you to pass the exam on the first try. 

I couldn’t allow this book to go out the door without acknowledging the efforts of the team at RMC 
that made this happen. In particular, I’d like to thank Margo Kirwin for her significant work in updating this 
book. I'd also like to thank Patti Frazee and Jason Craft for their dedication and hard work on this edition. 

Margo was a student of Rita's, served as RMC's Director of Training, and has trained on RMC products 
for a number of years. She has the knowledge and clarity to capture Rita's vision. In addition to being an 
outstanding trainer, Margo has an extensive background in instructional design, which she brought to the 
development of this edition. She is also a talented writer who was able to maintain the conversational tone 
and feel of the book while working hard to explain all the elements of project management in a clear and 
easy-to-read way. 

Patti served as the project manager and content editor for this book. Patti brought an incomparable set 
of skills that allowed her to help develop and edit content while also managing the constantly moving 
pieces of the project. Without her, this book would not have been published on time, if at all. 

Jason was the talented designer of this book. With a keen eye to detail and his creative sensibilities, he 
made this book visually appealing and engaging. He also took our vision of the RMC Resources page and 
made it a reality. 

When Rita created RMC, she did so to help people. That is still our goal and one of the driving values 
of this company. So enjoy the book, learn, and have fun. 


What are you waiting for? Go get ‘em. 


Tim Mulcahy 
President and CEO 
RMC Learning Solutions and RMC Publications 
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Studying for the PMP® Exam 


RMC has helped thousands of students worldwide pass the PMP* exam. In this section, we provide information on our 


proven study methods to help prepare you for the exam. We will also give you information on how to apply to take the 
exam and the requirements needed. In addition you will find the following: 


* A self-evaluation checklist: Discover the knowledge needed to pass the exam 
* How to use this book to maximize your studying time 

+ Some key definitions 

* Other tools from RMC that can enhance your studies 

+ What the PMP* exam is like 

+ Important aspects of the exam 

+ Sample questions 

+ PMI-isms 

+ Study plans 


1 Tricks of the Trade for 
Studying for the PMP® Exam 


Preparing to take the PMP® exam is a journey. This journey can help you grow your career and develop 
your skills and abilities. This isn’t just about passing an exam—you can become a better project manag- 
er. This opportunity to learn is one of the best reasons to get your PMP certification. 

To pass the PMP exam, you need to truly understand project management processes, good 
practices, and the project manager’s role and responsibilities. You also need to be able to tailor your 
tactics and strategies to the situations that different projects present—and to the different situations 
presented to you on exam questions. The PMP exam is designed to test your knowledge and experience 
in applying the art and science of project management. 


In addition to the learning opportunity, there can also be financial incentives for passing the 
exam. According to Project Management Institutes (PMI®) salary survey (2020), globally, 
PMP-certified project managers are paid on average 16% more than those without the certification. 
RMC has had students who received a bonus, a raise, or both when they passed the exam. Others have 
reported they landed a job ahead of other qualified candidates because they were PMP certified. 
Having a PMP certification can be the reason you get a job, keep your job, or are promoted. 


Qualifying to Take the Exam 


To take the PMP exam, you must meet the current requirements as summarized below and in the fol- 
lowing table. Requirements are subject to change, so make sure you review the requirements at 
pmi.org, or in PMI’s Examination Content Outline (ECO), where this information is published. 

+ Your experience leading projects cannot overlap. For example: If you managed two projects at the 
same time for six months, you may use your experience with only one of these projects for that 
six-month period. 

+ If you are a graduate of a PMI Global Accreditation Center for Project Management Education 
Program (GAC) program, you will receive a 12-month credit towards the required experience. 

* Work experience must be professional experience. For example: Managing a project to build 
your own house cannot be counted toward the work experience. 

+ In addition to the educational background and professional work experience found in the table 
on the next page, you must have at least 35 contact hours of formal project management 
education, unless you are an active Certified Associate in Project Management (CAPM)® holder. 
Active CAPM holders do not need these 35 contact hours of project management training. 


e Check PMI’s site to ensure that these requirements are current as PMP requirements are subject 
to change. 


QUICKTEST 


You will find a list at 

the beginning of each 
chapter of key topics 
covered in the chapter. 
Use the Quicktest to test 
your knowledge of those 
topics and uncover your 
gaps in understanding. 
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Educational Background Project Management Work Experience 
* Secondary degree (high school diploma, + Minimum five years/60 months unique 
associate degree or global equivalent) non-overlapping professional project 
management experience 
OR 
+ Four-year degree (bachelor’s or global + Minimum three years/36 months unique, 
equivalent) non-overlapping professional project 
management experience 
OR 
* Bachelor’s or post-graduate degree from a + Minimum two years/24 months unique, 
GAC accredited program (bachelor’s, non-overlapping professional project 
master’s or global equivalent) management experience 
This book will help you become familiar with the project management practices and terminology needed to pass the 


exam. If you don’t meet the minimum requirements listed in the previous table, consider taking PMI’s CAPM exam. You 
can find the requirements for the CAPM exam at pmi.org. 


Applying to Take the Exam 


Fa a ie, 
Applications to take the exam must be submitted online to PMI. Here is what the process looks like after you submit your 
application: 
+ You must log into pmi.org to see if the status of your application is “accepted.” 
* Once your eligibility is verified, you will need to pay for your exam.* * 
+ After you pay for the exam you can schedule it at a testing center. Alternatively, there is an option to take the exam 
online from your home or office. 
* Once you receive authorization to take the PMP exam, you must pass the exam within one year. You can take the exam 
up to three times within that year. 


* Ifyou fail the exam three times, you must wait one year to reapply for the exam. 


*A percentage of candidates are selected at random for audit. If you are selected for an audit, you will need to provide 
to PMI a copy of your degree, verification of your experience by a manager, and proof of your 35 training hours (with 
exceptions to these 35 training hours for active CAPM holders). 

There are specific rules and instructions for each type of exam (online or at a testing center). For online exams it is 
highly recommended to test your computer system with their testing system before exam day. In most cases, the 
confirmation of your scheduled exam will give you specific details. Consult PMI’s certification handbook and visit pmi.org 
for the most detailed and up-to-date information about testing options, locations, and exam languages available. 
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Are You Ready for the PMP Exam? 


In our experience, half of those who fail the exam do so because they have not had fundamental project management train- 
ing, or experience and training that uses PMI terminology and concepts. This is a serious factor to consider in determining 
whether you are ready to take the exam. This PMP*! Exam Prep book will help you understand project management from 
PMI’s perspective; however, if you find that many of the concepts and terms presented in this book are new to you—or you 
do not use many of the methods discussed in this book (such as a charter, WBS or prioritized backlog, network diagram, 
and management plans)— you probably need fundamental project management training before continuing to study. 

Other people who fail the exam do not have enough real-world project management experience and do not understand 
the range of possible project types and development approaches. Instead, they may be managing very small projects or 
repeatable processes. Some might not even be working as a project manager. On the exam, you will need to be able to 
recognize from the information in scenario-based questions what type of project the question is referring to, and to answer 
from that perspective. This could be a large project using a plan-based project management approach, a project using an 
agile approach, or an approach that is a hybrid of the two. The more experience you have with a variety of project 
management approaches, the better prepared you will be for the exam. 

The following are examples of projects that are likely to use a plan-based approach: 

+ Building a bridge 

+ Designing and constructing a new building 


The following are examples of projects that are likely to use an agile approach: 

+ Creating a new product that does not need to have all features before its first release but can instead be released with a 
set of defined, critical features 

+ Incremental delivery of a solution where scope is emerging 


The following are examples of projects or programs using a hybrid approach: 

* The construction of a new building uses a plan-based approach. Then, the division and finishing of the inside of the 
building into office suites is completed iteratively and incrementally as leases for suites are signed. 

+ An internal software product for a large organization is developed and tested using a plan-based approach. It is then 
rolled out to a small pilot group of end users. By the end of this predictive phase and pilot, the software installation and 
training have been field-tested. Installation and training for the remainder of the organization can be done iteratively 
by department and by office until the rollout is complete. 

+ A very large technology project may have several adaptive “feature teams,” each assigned to develop different software 
components. The project management work of integrating the features produced by the feature teams may be done 
using agile methods while development takes place. Predictive methods may be used for rolling out the solution to 
user groups. 


What is the depth of your knowledge and understanding of project management? Think about your project 
management training and experience as you review the following self-evaluation checklist. Do you understand most of 
these topics, and do you currently apply many of the methods included in these lists when working on your projects? 

This book will help you find and fill your gaps in the project management knowledge needed to apply to situational 
exam questions in order to pass the exam. However, the starting assumption is that with your project management 
experience and education, you are already familiar with many of these concepts. The more gaps you identify, the more 
effort you will need to apply to exam preparation. Most chapters in this book will provide a Quicktest, or list of concepts 
contained in that chapter. Use that and the other instructions we provide to be sure you are filling your gaps as you work 
through the material in this book. 
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Self-evaluation Checklist 


The following checklist provides an idea of the breadth of knowledge and the application of skills required to pass the exam. 


If you understand a list item, mark it off so that you can pay attention to those items where you have gaps in your knowledge. 


oO 


Oo 


Managing a project with the urgency needed to deliver the benefits and value for which the project was selected. 


Using a systematic, plan-driven project management process, and understanding why each step is necessary. Think 
about this as you review PMI’s Process Groups model in the “PMP* Exam References in Context” chapter and 
elsewhere throughout this book. Plan-driven and agile methods will be identified and compared. 


Agile philosophy for project management, and good agile practices from a variety of agile methods, including 
Scrum, Lean, and Kanban. 


The roles of the project manager, sponsor, product owner, team, and stakeholders. 

The use of historical information from previous projects, including lessons learned. 

What a formal project charter is and knowing what it requires. 

Prioritizing project constraints sufficiently to balance and manage competing constraints. 

What a work breakdown structure (WBS) is and how to create it. 

Creating a product and project vision sufficient to create a high-level product roadmap. 

Using a prioritized, risk-adjusted backlog of product features to create stories for iterations of product development. 


Understanding the interconnected relationship of activities (dependencies) to create the network diagram for a 
plan-driven project. 


What the critical path is, how to find it, and what benefits it provides the project manager. 


Using a variety of estimating techniques, including rough order of magnitude (ROM), three-point estimating, or 
relative estimating such as affinity sizing and story point estimating. 


Doing earned value analysis and management. 

Carrying out schedule “what if’ analysis and schedule compression (crashing and fast tracking). 
Managing project float and activities that do not have float. 

Creating a realistic schedule. 

Managing the quality of both the project and the resulting deliverables. 

Developing relationships with stakeholders, and keeping them interested and involved in the project. 


Using the meetings and feedback loops necessary to continuous progress and continuous improvement on agile 
projects—for example, daily standups, iteration review, and iteration retrospectives. 


Using information radiators to keep stakeholders informed and engaged. 

Understanding the process of risk management. 

Calculating reserves and understanding their relationship to risk management. 

Creating a realistic and approved project management plan that you are willing to be held accountable to achieving. 
Monitoring and controlling the project according to the project management plan. 

Managing change requests and controlling change. 

Planning and developing iteratively and incrementally for change-driven projects. 

Understanding the professional and social leadership responsibilities expected of a project manager. 


Ensuring that roles and responsibilities are clear and that team members are properly trained and oriented to the 
project and the selected life cycle and development approach. 
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How to Use This Book 


First, be sure you have the most current materials. This edition of the PMP*Exam Prep book is in alignment with the Exam- 
ination Content Outline (ECO) for exams taken after January 2021. It also uses concepts found in resources from PMI: 


+ The PMBOK* Guide, Seventh Edition (©2021) 

* The Standard for Project Management (published with the PMBOK* Guide) 
* Process Groups: A Practice Guide (©2023) 

+ Agile Practice Guide (©2017) 


Does this mean you have to read all these resources? No! We have researched what you need to know for the exam and 
have provided that information in this book. 


How Terminology Is Used 

It’s important to define some terms up front. We have listed these here. You will find other terms described in the chapter 
where they have the most context. If a term is not defined, we may have assumed that it is a fundamental project management 
term, and most people understand it as common knowledge. PMI provides a Lexicon of Project Management Terms in 
their list of standards and publications (on pmi.org). 


Project Environments and Project Management Approaches 


Project Environment Some organizations use a single type of project management approach, like plan-driven or agile. 
Other organizations use a variety of approaches across the spectrum from plan-driven to agile, and hybrid. This will depend 
upon a variety of factors, including the type of organization, the types of products or services the organization creates and 
supports, organizational governance, and the characteristics of the projects the organization needs to complete to achieve 
its strategic goals and deliver value to its stakeholders. 


Project Approach (or development approach) This refers to a selective approach to project management and product 
development based on the type, size, priority, and complexity of a particular project. Among other considerations, the 
project approach is typically selected based on how possible it is to accurately define scope and other project constraints 
early in the project. There is a spectrum of approaches from plan-based to agile, and hybrid. 

When we talk about project environments we are generalizing about the project management (or development) 
approach that an organization tends to use or is using for a variety of projects at the present time. In everyday language this 
terminology is used differently depending on the organization, project management office (PMO), or project team. For 
consistency and to avoid confusion in this book we use the following terminology to describe project environments and 
project management approaches: 


+ Environments We describe project environments as either predictive, adaptive, or hybrid. 
+ Approaches We describe project management approaches as either plan-driven, agile, or hybrid. 
>/ A plan-driven approach is also knows as traditional or waterfall (or predictive). 


>/ An agile approach may also be known as adaptive. Some people use the terms agile and Scrum interchangeably, 
even though Scrum is a specific agile methodology. 


Project Life Cycle _ 


A life cycle is a progression through a series of developmental stages. The project development life cycle reflects the 
performing organizations’ methodology for managing a project. It is a logical breakdown of what the project manager 
needs to do to produce the project deliverables, and is selected based on factors such as the type of product being developed, 
the industry, the organization’s preferences, and the development approach. 

A project life cycle can use a plan-driven or change-driven development approach, or a hybrid of the two. An example 
of a life cycle for new product development might include the following phases: research, design, build, test, and implement. 
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How This Book Is Organized 


This book contains six exam content-related sections. 


Section I Tricks of the Trade for Studying for the PMP Exam 


This is the only chapter in this section. 


Section IJ Foundations 

This section of this book is where you will learn the base knowledge that you need to understand the rest of the content of 
this book and to begin preparing for the exam. 

“Exam References in Context” This chapter provides foundational information about the: 

+ Examination Content Outline (ECO)—which exam question writers are directed to use when writing exam questions. 

e PMI’s Process Groups Model—is found in PMI’s book, Process Groups: A Practice Guide. We refer to the content of 
Process Groups: A Practice Guide as the “Process Groups model” because we consider it a great learning model for plan- 
based approaches, which make up a large proportion of exam questions. Your understanding the Practice Groups 
model will also help you understand the tasks of the ECO, and it also informs many of the practices understood to be 
part of the plan-based components of hybrid project management approaches. 

e  Rita’s Process Chart'”, a vital study tool that has helped many thousands of students prepare for the exam by 
summarizing the detailed plan-driven approach to project management. 

e Rita’s Agile Process Chart”, another vital study tool that will help students prepare for the exam by summarizing an 
agile approach to project management. 

+ Agile Approach Overview. 

+ Hybrid Approach Overview. 

+ PMBOK* Guide, Seventh Edition Overview. 

“Project Management Foundations” This chapter discusses basics like projects, programs, portfolios, and organizational 

and project governance. It also discusses organization types, project selection, and project roles and responsibilities. 
“Integration” This chapter discusses arguably the project manager’s most important job, which is to provide the necessary 
leadership to bring the needs of many stakeholders and the work of team experts together into a cohesive whole to 
successfully deliver the business value for which the project was selected to the organization and its stakeholders. 

The next three sections of the book discuss the information you need to know for the exam from the combined 

perspectives of the ECO domains, the Process Groups model, and plan-driven, agile, and hybrid practices. These 
sections are: 


Section HI: The ECO People Domain 
Section IV: The ECO Process Domain 


Section V: The ECO Business Environment Domain 


Section VI: How to Pass the First Time 
This section of the book follows up on what you have learned, with instructions for continuing your studies until you are 


prepared to sit for and pass the PMP exam. It includes the following chapters: 
+ “Tips for Passing the PMP* Exam the First Time” 
+ “Common Agile Methodologies” 
+ “Additional PMBOK* Guide, Seventh Edition Concepts” 


Book Chapter Organization 

Most of the chapters in this book have been organized the same way: an introductory discussion, a list of Quicktest topics, 
an overview of the process, and review materials. This PMP* Exam Prep book can be used alone, but it is also part of our 
PMP Exam Prep System that includes our PM FASTrack* Cloud exam simulator as well as our Hot Topics flashcards. With 


8 


your book purchase you receive access to our new tool, RMC Interactive Chapter Quizzes. 


ONE Tricks of the Trade for Studying for the Exam 


Each of chapters four through nineteen contains: 


* Introduction and processes overview The introductory discussion provides key information for understanding 
the material covered in the chapter and definitions of some key terms. The overview begins your understanding of the 
main concepts and processes. 


* Quicktest The list at the beginning of each chapter indicates the key topics covered in the chapter. To test your 
knowledge of chapter content and to review what is most important, refer back to this list when you are finished with 
each chapter. Use the Quicktest to test your knowledge of those topics and uncover your gaps in understanding. 


e Graphic tables and process overview charts These outline key ECO tasks as they relate to the Process Groups 
model, along with associated content from PMBOK* Guide, Seventh Edition. The process overview charts in the 
Process domain chapters will give you a high-level graphic view of each process. 


e Review materials and exercises This book contains extensive review materials and exercises within each of these 
chapters, where applicable. These materials have been developed based on accelerated learning theory and an 
understanding of the exam content. 


The answers are listed immediately following the exercises. We have found that it is most effective to place the answers 
right after the exercises rather than later in the book. Do not skip the exercises or go straight to the answers, even if their 
value does not seem evident to you. The exercises and activities are key benefits of this book and will help you pass the 
exam. Actively working with the information by doing the exercises on your own before checking the answers will better 
prepare you than if you just passively read the answers. 


Exercise Notebook For the exercises, you’ll be prompted to create and use an Exercise Notebook. While some people 
will have our BMP* Exam Prep book in a printed form, many others will have access to our digital book. Because of this, we 
encourage users to create a separate notebook (either physical or electronic) to record answers. The important thing is to 
actively produce the answers to the exercises in a place you can come back to for review, and to make any other notes that 
will help you review the material for the exam. 

We have numbered each exercise and encourage you to record these numbers in your Exercise Notebook. Use this 
tool to keep track of any gaps in your knowledge. Pay attention to any patterns in gaps. At any time, you may review your 
notebook for anv incorrect answers or retrv an exercise. 


TRICKS Included in the review material are tricks to passing the exam called Tricks of the Trade*. These tricks are 
OF THE designated by the image shown here to the left and will give you some extra insight about what you need to 
8131/10) know about project management and how to study for the exam. 


Think About It. This icon indicates a section where you will be asked to slow down and really think through 
a concept being presented. The “Think About It” sections will sometimes present a scenario and ask you to 
aa consider how it should be addressed; other times it may present more information on the topic at hand. 


~~ 
(A) Agile Focus When we delve into the agile aspect of a topic, this icon will appear next to the text. Use it to 
P easily find where agile concepts are being presented. 


RMC Resources Web Page 

New information about the exam is always emerging. RMC offers a web-based resource to help you P 
stay up-to-date on materials. Our RMC Resources web page (rmcls.com/rmc-resources or scan the ` fød 
QR code) is a robust study tool that provides supplemental material for you to work with as well as 
errata and other updates to this book. RMC Resources includes interactive games, more in-depth 
information on particular topics, a project management glossary, and more. As we observe trends 
relevant to exam prep, we will publish additional materials on RMC Resources. Be sure to review the [E] 

materials at RMC Resources to see which items will be of most help to you in preparing for the L a 
exam. We will refer to RMC Resources throughout the book where appropriate and provide the QR 
code for easy access. 


RMC RESOURCES 
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RMC Interactive Chapter Quizzes 

The RMC Interactive Chapter Quizzes is an interactive tool with questions that pertain to chapters 2 through 15, which 
allows you to review the material and test your understanding. Refer to the “How to Study for the PMP Exam” section on 
page 22 to understand how and when to use these practice exams as part of your study plan. This tool will show you how 
you scored on the chapter quizzes as you work with this tool. 

The questions in the chapter quizzes are representative of the knowledge and principles tested on the exam. Keep in 
mind that you cannot simply practice answering questions to prepare for the exam. The questions in the RMC Interactive 
Chapter Quizzes help you assess your knowledge and become familiar with the types of questions on the exam. Make sure 
to focus your study efforts on reading this book, doing the exercises and review activities, and filling gaps in your project 
management knowledge. 


10 


What Is the PMP Exam Like? 


Keep in mind three important things about the PMP exam. First, the exam is not a test of the information in the PMBOK* 
Guide. Its questions are written by project managers with the PMP certification, based on real-world situations. Second, 
while your real-world experience is essential to helping you pass the exam, you cannot rely on it alone. Third, training in 
professional project management that is aligned with the ECO, the Process Groups model presented in Process Groups: A 
Practice Guide, and the Agile Practice Guide is critical for exam success. 

The exam includes 180 questions, all of which are situational. The questions may appear in one of five different 
formats. These include multiple-choice, multiple responses, matching, limited fill-in-the-blank, and hot spot (e.g., you are 
asked to place identifying plots on a chart). See the Question Examples section in this chapter for examples of these 
question formats. The exam must be completed in 230 minutes, which is just under four hours. You will be given the 
opportunity for two 10-minute breaks during which the exam timer pauses. 

You will be scored on 175 of the 180 exam questions (since five are newly written “trial” questions that will not be 
scored). PMI does not publish what it considers to be a passing score. Based on exam history, however, we estimate that it 
is somewhere between 61 and 64 percent (about 110 to 114 questions correct out of 180). 

The questions are randomly generated from a database based on how many questions must be included from a 
particular content area (the ECO People domain, for example). One point is given for each correct answer, and of course, 
you must accumulate enough correct answers to exceed the passing threshold. 

The following table shows the percentage of scored questions on the exam for each Examination Content Outline 
(ECO) domain. 


Examination Content Outline (ECO) Domains Percentage of Questions 


People 42% 
Process 50% 
Business Environment 8% 
TOTAL 100% 


The “PMP® Exam Reference in Context” chapter contains more detail on ECO domains. PMI occasionally 
makes changes to aspects of the exam, including the qualification requirements, the application 

process, and the breakdown of questions in each domain. For the latest information, please visit 

pmi.org and read the ECO, the Certification Handbook, and your authorization notice carefully. Any 
differences between what is listed here and what is communicated by PMI should be resolved in favor 

of the latest information posted on pmi.org. 
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Additional Important Aspects of the Exam 


+ The exam tests knowledge, application, 


and analysis. This makes the exam more than a test of memory. You must 


know how to apply the information in this book and be able to analyze situations involving this information. Do not 


expect the exam to have a majority of straightforward, definition-type questions. 


* The exam deals with practical experience. Questions are based on a situation, described in each one. For those who do 


not have the appropriate project management experience, these questions can be very difficult. 


+ There may be instances on the exam where the same data are used for multiple questions. You may also see data 


repeated in answer choices. 


+ Many questions focus on “what should the project manager do” in the given question situation. It is important not just 
to understand project management processes, but to understand the relationships of artifacts and methods related to 


these processes. 


*/ As you recognize a process on an 
(sometimes referred to as inputs) and 


exam question you should be able to bring to mind what artifacts 
what methods you need as a project manager to carry out the process. 


For example, in order to carry out a Manage Stakeholder Engagement process properly, you need a 
stakeholder engagement plan (which is part of the project management plan for plan-based projects). 


>/ You must also understand what artifacts you have as a result of a particular process once it is carried out 
(sometimes referred to as outputs). A process often results in updates to some of the same artifacts you 


needed to use to begin the process. 


For example, the stakeholder engagement plan (created during the Plan 


Stakeholder Engagement process) is used and followed during the Manage Stakeholder Engagement 


process, but the plan is also updated 


m/ In addition to artifacts and methods 
of processes. In the previous examp 
that result from the work, but you al 
their expectations appropriate to proj 
project and its results. 


. 


Historically, there have been up to 6 or 7 
only | to 3. 


as a result of the Manage Stakeholder Engagement process. 


or carrying out processes, you should understand the desired outcomes 
e of the Manage Stakeholder Engagement process, there are artifacts 
so have good relationships with your stakeholders, are able to manage 
ect conditions, and therefore achieve stakeholder satisfaction with the 


‘ormula-related calculations on the exam, but more recently there have been 


Expect 7 to 10 earned-value questions on the exam. Note that most earned value questions focus primarily on your 


understanding of the concepts behind earned value and not on performing calculations. 


typically uses the full term “work breakdo 
acronym and the full term for the exam. 


* Most people feel uncertain about only 36 


Project management terminology often uses acronyms. Most acronyms will be spelled out (for example, the exam 


wn structure” rather than “ WBS”) Nevertheless, you should know both the 


or fewer of the 180 questions on the exam. Concentrating on understanding 


the concepts and being able to think holistically about these concepts will contribute to your confidence in answering 


questions. 


y Mark for Review to tag questions you are 


The exam software has tools helpful in processing questions. For example, you can use: 


unsure of, to come back to later before you submit the exam, 


y Highlight parts of a question you think are most important to the situation and to selecting the right answer, 


y Strikethrough parts of a question you think are least important to the right answer or are “distractors” that 
will complicate your ability to correctly answer the question. 


Question Examples 
Questions on the exam are situational, meaning 
given scenario rather than just giving a textbook 


to answer them you must apply your knowledge and experience to the 
response. Many questions are ambiguous. Questions often seem like they 


have two or more right answers. Prepare for the following types of questions so you will not be caught off guard when you 


are taking the exam. 
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Situational questions These demonstrate why project management experience and knowledge of good practices 
are critical to passing this exam. Such questions require you to align your real-world experience with knowledge of 
the exam concepts. For example: 


Question The project manager receives notification that a major item they purchased for a project will be 
delayed. What is the best thing for the project manager to do? 


A. Replan the project to accommodate this delay. 

B. Notify the project sponsor. 

C. Let the customer know about it and talk over options. 
D 


Meet with the team and identify alternatives. 


Answer D 


Questions with two or more right answers Multiple choice questions that appear to have two or more right 
answers are a major complaint from test takers. These questions, which list several choices that could reasonably 
be done, require analysis and the process of elimination to find the best answer for the given scenario and 
question details. 

As you go through questions and review the answers in the RMC Interactive Chapter Quizzes, look for questions 
you think have more than one right answer and try to figure out why you think multiple choices are correct. We have 
intentionally included such questions in the RMC Interactive Chapter Quizzes to give you exposure to these types of 
questions. We provide explanations to help you understand why your right answer may not be the best choice. 

Let’s look again at the previous situational question. Couldn’t we really do all the choices? The right answer is D, 
but isn’t it also correct to tell the customer? Yes, but that is not thefirst thing to do. This question is really saying, “What 
is the best thing to do next?” or “What should the project manager do next?” As you answer practice questions, keep 
in mind the concept of the “best thing to do next” to help you decide which answer identifies the project manager’s 
responsibilities in the given situation. 


Note: By “proper project management” we generally mean project management according to systematic and 
agreed-upon good practices. More specifically for the exam, if we are talking about the order of activities within a 
process, it should relate to how processes are described in the ECO domains, the Process Groups model, or the Agile 
Practice Guide. We know that processes can vary in their order of activities but as PMI has sometimes been specific on 
this, we will be specific as well. In other words, for the exam we mean “proper project management” according to PMI. 
Be careful—this will sometimes not align with your everyday project management experience. 


. Questions with extraneous information Not all information in a question will be relevant. 


Question Your next project involves managing an agile initiative to distribute new driver management software 
to your firm's taxi fleet. At this point the project steering committee is debating whether to contract with a usability 
testing service for the project. They ask for your input on whether this would be cost-effective. You reply that while 
you don't have the specific data yet, as a general rule: 


A. The most economical time to test would be near the end of the project when the screens are done and less 
likely to change. 

B. Finding issues earlier is always preferable since it is likely to save a lot of money in the long run. 

C. Defects found by the developers are less costly to fix than those found in review or testing. 


D. Testing the screens near the end of the project will leave little time to incorporate changes. 


Answer B 


In this example, the type of system being developed (driver management) doesn’t affect the answer. It is extraneous 
information meant to distract you. 
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4. Questions using made-up terms Many people taking the exam expect that all the terms used as choices should 
mean something. That is not the case. Answer choices sometimes include made-up terms. If you consider yourself 
well prepared and see a term on the exam you do not know, chances are it is not the right answer. For example: 


Question The WBS, estimates for each work package, and the network diagram are completed. The next thing 
for the project manager to do is: 

A. Sequence Activities 

B. Develop Schedule 

C. Validate Scope 


D. Resource Simulation 


Answer B 


In this question “resource simulation” (choice D) is not a real project management term. 
5. Questions where understanding is important. Let’s look at the following question: 


Question The senior web designer on a project just came down with the flu in the middle of an iteration. What 
should the project manager do? 

A. Meet with the team to find out how much of the planned work will be done. 

B. Ask the two other designers to work overtime this week. 

C. Ask the product owner to postpone the product demo until the iteration goal is done. 


D. Call the web designer's functional manager and ask for a new designer for the rest of the iteration. 


Answer A 


In order to answer this question, you must understand iteration timeboxes and how agile teams work. 


6. Questions with a new approach to a known topic There will be many instances where you understand the topic 
but have never thought about it as described. For example: 


Question A product is being built iteratively on a new technology platform. When the project manager asks the 
team members about the quality of the early product increments, they say "They're fine." How can the project 
manager verify that the new technology is supporting the quality objectives of the project? 

A. Ask the team to present performance testing results showing the actual vs. expected measures. 

B. Ask the product owner how well the technology is delivering business value. 

C. Present the quality management plan to the team's coach and ask if the technology is supporting the plan. 

D 


Bring in an auditor to assess the quality. 


Answer C 


Seeing the words “iterative” and “increments” should make you think this is an adaptive life cycle project but that 
might steer you away from an answer referring to a management plan. Management plans can be used on adaptive 
and hybrid project life cycles if the project manager sees value in the plan. 
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7. Questions with more than one item in each choice Let’s look at the following example: 


Question The seller has presented the project manager with a formal notification that the seller has been 
damaged by the buyers activities. The seller claims that the buyer’s slow response to the requested approvals has 
delayed the project and has caused the seller unexpected expense. The first things the project manager should 


do are: 
A. Collect all relevant data, send the data to the company attorney, and consult with the attorney about 
legal responses. 


B. Review the contract for specific agreed-upon terms that relate to the issue, see if there is a clear response, and 
consult an attorney if needed. 


C. Review the procurement statement of work for requirements, send a receipt of claim response, and meet to 
resolve the issue without resorting to legal action if possible. 


D. Hold a meeting with the team to review why the acceptances have been late, make a list of the specific reasons, 


and correct those reasons. 


Answer B 


These questions can seem hard until you apply this little trick. Use the process of elimination, one item at a time. 
Consider the first item listed in each choice and eliminate the choices that contain an implausible first item, if 
applicable. Then look at the second item in each remaining choice and eliminate any implausible choices. Keep 
going until you have one choice remaining. 


Watch out! Sometimes the items in each choice show a flow or process. See the following example to think about 


how sometimes the items in each answer choice show a flow or a process: 


Question A resource issue has come up on a construction project. Which of the following is the best way to deal 
with the problem? 

A. Go to the team, go to management, go to resources managers 

B. Go to resource managers, go to management, go to the customer 

C. Handle it yourself, go to the customer, go to management 
D 


Resolve problems with resources you control, go to resource managers, got to the customer. 


Answer D 


In this case you need to look at each choice independently to see if the process listed is correct. 


8. Excessively wordy questions Instead of saying “The project is behind schedule,” the exam might use wordier 
phrasing such as “The project float was zero and has recently gone to negative 2.” Instead of saying “The team is not 
reporting properly,” the exam could say “The team has lost sight of the communications management plan.” The 
first step in answering many questions is to determine what the question is really asking, and then to translate the 


wordy phrasing. 


Tricks of the Trade for Studying for the Exam ONE 


Questions in Different Format Types 
Our examples so far have used a typical multiple-choice format to point out specific characteristics of the way questions 
are worded on the exam. Now take time to look at the other, newer question formats that are used on the PMP exam. 


1. Multiple responses answer Questions using this format ask you to choose two or three correct answers, as in this 


example: 


Question Several stakeholders have different opinions about the product requirements. Which two of the 
following techniques could the project manager use to bring the group to consensus? 

Facilitated workshop 

Interview 

Backlog refinement session 

Observation 


Survey 


mmo w > 


Mind mapping 


Answer A, C 


2. Hot spot questions These types of questions show you a graphic on which you will have to click a “hot spot” 
containing the correct answer: 


Question Review the Burnup Chart. The team’s velocity has averaged 4.6 story points per iteration with 27 
points completed. The project scope was increased during iterations 3 and 4 to a total of 48 story points. 
Management would like the project scope to be completed by iteration 9. What should be the team goal for 
iteration 7? Click on the diagram showing the next data point in the Work Accepted line. 


Story Points 


1 2 3 4 5 6 7 8 9 
Iterations 


To answer the question, click on a “hot spot” on the diagram as shown below. 


Story Points 
8 


1 2 3 4 5 6 7 8 9 
Iterations 
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Matching question Questions in this format will give you two columns of concepts to match. In the following 
example, the test taker would drag the cards in the “Action” column to to the center box that aligns with the “Order 
in which to perform” column. 


Question During a team retrospective, the project manager senses a conflict. In what order should the project 
manager use the following actions to address the conflict? 


Action Order in which to perform 
E m 
— sen 
Observe the situation and listen to Third 
both sides 
Assess the group's energy, words and Fourth 
body language 
Answer 
Action Order in which to perform 
Decide what, if any, intervention is needed Observe the situation and listen to First 
both sides 
f confi 
Determine the level of conflict iegroups j es ES 
body language 
Observe the situation and listen to 
ee \ Determine the level of conflict Third 
Assess the group's energy, words and Decide what, if any, intervention is needed Fourth 


body language 


4. Limited fill-in-the blank These types of questions will ask that you type the answer (represented by a blank 
space in the question) in a box given: 


Question Review the fishbone diagram for the problem: Increased customer complaints. Enter the 


indicating the area that includes the possible causes of the problem related to people. 


L] 


Poor morale 


Poor quality control 


Employee procedures are wrong Not enough resources 


Lack of training 


Lack of clear employee procedures 
Increased 
customer 
complaints 


Poor software usability Product components 


of low quality 


Login screen confusing 


Confusing product 
descriptions 


Out of date technology 


Answer C 


letter 
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Recurring Themes—PMI-isms to Know for the PMP Exam 
RMC has been helping people pass the PMP exam and become better project managers for more than 30 years. During 
that time, we have developed the following list of “PMI-isms” the exam assumes but many project managers do not know. 
We suggest you read it now and then remember to reread it along with the Tricks of the Trade in this book, before you take 
the actual exam. Assuming PMI-isms to be true (unless the question evidence says otherwise) will help you pick the best 
answer from what seems like more than one correct answer. Look for PMI-isms in the “Quality of Deliverables and 
Products” chapter as well. We have some there that are specific to quality. For the exam, assume that you have (or do) all 
the following and that these concepts are true for your projects. As you review these PMI-isms, think about which ones are 
true for your projects. If there are any that aren’t true for your projects, you may have a gap in your knowledge. It’s important 
to make note of any gaps you may have and review these gap areas as part of your overall study plan. 

Important: PMI represents project management practices along a range of approaches that are predictive, adaptive, 
and hybrid (a combination of approaches). As you study these PMI-isms, keep in mind that a project manager should tailor 
the approach to fit the needs of the project. 


General PMI-isms 


o Without a skilled project manager, the vast majority of projects will fail. With a person educated in the skills of 
project management, regardless of title, a project has a high likelihood of success. 


o The project manager puts the best interests of the project first—not their own interests. 


o The project manager understands the value of the principles, methods, models, and artifacts of project management 
and knows how to adapt them to the type of project they are managing. 


a The project manager is assigned during project initiating (or sooner), not later in the project. 


o The project manager understands the process of project management (i.e., what to do first, second, etc., and why) 
and has the ability to make proactive tailoring decisions. 


a Organizations have a formal project selection process, and they choose projects based on how well those projects 
meet the organization’s and its stakeholders’ needs and strategic goals. 

o The project manager understands why their project was selected. They ensure while planning and managing the 
project that the project delivers the benefits and value for which it was selected. 


o The project manager and team create a product and project vision and the project manager works throughout the 
project to foster a common understanding of the product and project vision. 


o The project manager plans, manages, monitors and controls scope, schedule, cost, quality, risk, and resources, 
using projects to deliver value to the organization and its stakeholders. 


o In an adaptive environment, the agile coach (or Scrum Master) ensures that the appropriate processes and tools 
and techniques are well understood and being followed. 


o Agile teams are empowered to manage their own work according to objectives as prioritized by a product owner 


(or value management team). 

o Teams are trained and coached by the project manager (agile coach, Scrum Master) for skills appropriate to the 
approach being used on the project on which they are working. 

a Agile teams are coached to not just know agile processes but to “be” agile. 

o Each project is approached holistically and managed and executed as a value delivery system for the organization 
and its stakeholders. 

o Team members are motivated, empowered, and engaged, and come prepared with suggestions; they don’t require 
micromanagement from the project manager. 

o Organizations have a project management office (PMO), and that office has important, clearly defined 
responsibilities regarding projects across the organization. 

o Organizations have project management policies, which the project manager complies with on their project. These 
policies may include project management methodologies, risk procedures, quality procedures, and development 


18 


approach preferences. 


o 


ONE Tricks of the Trade for Studying for the Exam 


Projects have a beginning and an end and are used to create unique solutions to solve particular business problems 
and serve particular business needs. 


A project may be part of a program or portfolio, and the projects relationship to other projects could significantly 
influence how the project manager works. 

Organizations keep records (e.g., historical information and lessons learned) from previous projects that include 
planning artifacts and artifacts of the projects actual results. The project manager uses these organizational process 
assets to plan their project. The project manager then feeds their own projects records and lessons learned back 
into the organizations knowledge base. 


Organizational governance includes policies related to safety, diversity, and inclusion and a variety of other social 
responsibilities meant to protect workers, stakeholders, the organization, and society at large. Project managers 
proactively learn these and use them on projects. 


Project managers and other organizational leadership are screened for and otherwise trained in, and practice, 
emotional intelligence in relationships with the team and project stakeholders, as part of their leadership skills. 


The project manager works within the existing systems and culture of a company (enterprise environmental 
factors), and one of a project’s results is to provide input to improve those systems. 


Every project has a project charter, which authorizes the project and the role of the project manager. 


Every project has adequately planned and executed transition of the product of the project to the customer (or 
operations, for internal projects). The transition is an integral part of the Close Project or Phase process. 

A work breakdown structure (WBS) and WBS dictionary are used on all plan-based projects. An agile project 
manager uses a product backlog, a product roadmap, story maps, and stories. 
A project management plan is a series of management plans. The project manager creates a project management 
plan and other project artifacts tailored to the projects’ development approach and life cycle, and other specific 
project characteristics. 


The project manager keeps all project artifacts current to help manage and control a project. 


Stakeholders are involved throughout the project. Their needs are considered while planning the project and 
creating the communications management plan and the stakeholder engagement plan. 


People must be compensated for their work and deserve a fair and positive environment in which they can 
contribute their best work. 


Agile project stakeholders are represented by a product owner as part of the team. Team members can see 
stakeholder perspectives through the use of personas and other agile tools. 


Agile team members engage daily with stakeholders either directly or through the product owner to design and 


build the product, conduct iteration reviews, and then use iteration retrospectives as part of their own continuous 
improvement process. 


Gold plating (adding extra functionality) is not in the best interests of the project and should be prevented. 
Projects are managed in a matrix environment in which tools and techniques are typically straightforward. 


However, it’s important to know that concepts and tools such as motivation theories and conflict resolution may 
become more complicated in alternate environments. 


The project manager has a professional responsibility to properly use and tailor tools and processes appropriate to 
the selected development approach and life cycle. 

Project managers practice servant leadership to facilitate success of the team and the project. They are trusted 
stewards of organizational and stakeholder resources and needs and carry out their responsibilities in the best 
interests of both. 

Stewardship for the project managers include holistic points of view and holistic practices to carry out their 
financial, social, technical, and environmental responsibilities to the organization, its teams and stakeholders, and 


the larger society. 


Project managers are knowledgeable about the business environment and carry out their responsibilities related to 
environmental factors affecting the project or factors that the project affects. 
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Planning the Project 


o 


All projects must be planned using planning processes tailored to the project. 


In a predictive environment the project manager plans the project with input from the team and stakeholders. 
Adaptive environments include the whole team to do the planning. 


Planning involves selecting a project life cycle and development approach suitable for the project. 
Each project constraint plus other factors important to project success (requirements and scope, schedule, cost, 
quality, resources, communications, risk, procurement, stakeholder management) will be planned, managed, and 


controlled. Plan length and detail may vary by size, complexity, and priority of the project as well as by 
evelopment approach. 


In agile environments a project manager uses guidelines from an appropriate holistic and formalized methodology 
established according to the performing organizations goverħance. 


[he project manager, team, and other appropriate subject matter experts determine quality measurement metrics. 


[he project manager plans for and practices continuous process improvement. 


e project manager creates and uses a recognition and rewards system appropriate to each project. 

The project manager clearly documents and assigns project roles and responsibilities with the help of the team. 
[hese include reporting responsibilities, risk management assignments, meeting attendance, and project work. 
Agile teams have generalizing specialists who are experts in one or more field but can and will help in other areas 
where needed. 


[he project manager and team focus with rigor on identifying risks in alignment with the approach. 


[eam members and other stakeholders participate in risk identification and risk management responsibilities. 


The project manager and team appreciate that managing risks saves the project time and money. 
Project cost and schedule cannot be finalized without completing risk management. 


Plan-based project management includes creating realistic schedules and budgets based on the project’s defined 
scope. Agile project management entails being flexible with scope while keeping schedule and cost realistic 
and fixed. 


The project manager assesses whether a plan-based project can meet the end date(s) and other project constraints 
and objectives. They meet with management to resolve differences before project work starts. The project manager 
knows unrealistic schedules are their fault because they have tools and skills to help solve them. 

The project manager for an agile project establishes the minimally viable product (MVP) that can be delivered 


within the cost, schedule, and other project constraints. They provide plans for delivering the MVP in releases 
through iterative and incremental product building and delivery. 


The project manager plans when and how to measure performance against the performance measurement baseline, 
as documented in the project management plan. They plan for other methods, like value stream mapping, to be 
used to determine how the project and processes are performing while the work is being done. 


The project manager plans for stakeholder engagement at all levels and creates tactics to establish and maintain 
stakeholder engagement at the desired level for each stakeholder or group. 


The project management plan is realistic, and everyone believes it can be achieved. 


The project manager holds a kickoff meeting with the team. 
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While the Project Work Is Being Done 


The project manager is responsible for facilitating documentation and knowledge sharing during the project. 

The project manager measures against the project management plan to help determine project status throughout 

the life of the project. 

Projects are re-estimated throughout the life of the project to make sure the end date(s) and cost objectives will be 
met. Therefore, the project manager almost always knows if the project can meet the agreed-upon end date(s) 
and budget. 


The project manager has authority and agency. They can say no and work to control the project for the benefit of 


he organization and its stakeholders. 


A change in scope must be evaluated for its impacts to the project’s schedule, cost, quality, risk, resources, and 
customer satisfaction. The project manager has enough data about the project to do this analysis. 


The project manager realizes that, over time, people associated with the project may have different understandings 
about what the project is and what could occur during the project life cycle. The project manager is continually 
facilitating a common understanding and appropriate expectations. 


The project manager understands, and takes seriously, resource responsibilities on a project. 


[he project manager spends time on such activities as team building and ensuring high team performance. 


The project manager is proactive, finds problems early, looks for changes, and prevents problems. 

Risk is proactively managed. Most issues that occur have risk response plans to deal with them. Agile teams work 
with a risk-adjusted backlog that includes risk response plans. 

Risks are addressed at every team meeting. 
Project meetings have planned agendas that are followed. Agile team meetings take the form of daily standup 


meetings that are short and follow their set agenda strictly. 
All changes to a project management plan flow through the change management process and integrated change 


control (or its agile equivalent). 


The project manager and team execute and control the project with the urgency needed to accomplish the goals 
and objectives for which the project was undertaken. 

The project manager ensures that the project is compliant with organizational governance and with any applicable 
laws and regulations external to the organization. 

The project manager recommends improvements to the performing organizations’ standards, policies, and 
processes. Such recommendations are expected and welcomed by management. 


Quality should be considered whenever there is a change to any component of the project. 

Quality should be checked before an activity or work package is considered completed. 

The project manager works closely with the quality department in performing some of the quality activities 

discussed in Process Groups: A Practice Guide. 

The project manager is actively involved with the procurement process and assists in managing procurements. 
The project manager understands contract language. 


The project manager makes sure all the terms of a contract are met, including those that do not seem important. 
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Closing the Project 


o No project is complete until the product is transitioned to the stakeholders, and training has been provided on use 
and maintenance of the product to realize its benefits, as needed. 


a No project is complete until there has been final acceptance from the customer. 


o All projects produce a final report that gives the project team a chance to announce the project objectives have 
been met. 


o The project manager and team ensure that all project records are updated and archived. 


Which items in this list seem different from the way you or your organization manages projects? Which of these items 
do you not understand? Review this list when you think you are finished studying. Pay particular attention to those items 
that aren’t true of your projects. Are there any items you need to think about more to make sure you will remember them 
when you take the exam? Knowing these PMI-isms can make a significant difference. Most students have everyday project 
management experience that differs from a good number of these PMI-isms, making this a significant gap that students 
need to bridge before taking the exam. 


How to Study for the PMP Exam 
a 


Some people believe you need to read every known resource available, watch lots of videos and spend as much time as 
possible preparing for the PMP exam. Do not make that mistake. You should not read everything you can find, as some 
resources are not well vetted. We recommend the approach outlined in the following sections. 


The Magic Three Studies have shown that if you visit a topic three times, you are more likely to remember it. Read this 
book once and then skim through it two more times, focusing most on the activities you do not do in the real world and on 
the concepts you have trouble understanding or remembering. You should document these as you work through this book 
as they represent the gaps in your knowledge and understanding to fill before the exam. 


Be in Test-taking Mode Get used to jumping from one topic to another. You'll also need to practice answering questions 
for four hours. You can do this by waiting to do any chapter quizzes until you feel ready to answer the questions. Then take 
all of RMC Interactive Chapter Quizzes in one sitting (see step 4 in plan B on page 24). Do not underestimate the 
physical, mental, and emotional aspects of taking an exam lasting that long. You can also get into test-taking mode using 
our PM FASTrack® exam simulator. 


Your Step-by-Step Study Plan 
We recommend that you use one of the following study plans. Follow Plan A if you own RMC’s complete PMP Exam Prep 
System (This PMP* Exam Prep book, the PM FASTrack® Cloud Exam Simulator license, and Hot Topics). Follow Plan B if 


you own only the book and not the entire system. 


Plan A: Using This Book with the PMP Exam Prep System 
(PMP® Exam Prep book, PM FASTrack® Cloud Exam Simulator, and Hot Topics) 

One common mistake people who purchase the PMP® Exam Prep System make is to spend most of their study time 
answering questions in PM FASTrack®. This approach won’t work. As we mentioned earlier, focus your efforts on reading 
this book, completing the exercises and review activities, and filling the gaps in your applicable knowledge of proper 
project management practices for plan-based, agile, and hybrid projects. Use the following steps to study this book along 
with PM FASTrack® and Hot Topics: 

Read this book for the first time and complete the exercises. Spend more time on the areas where you recognize you 
have knowledge or experience gaps; items you did not know or do prior to beginning this course of study. Refer to Rita’s 
Process Chart™ and Rita’s Agile Process Chart™ frequently (included in chapter 3 of this book). Be sure you understand all 
the efforts involved in the topics you are working on. Use the ECO as directed in each of the ECO domain chapters to 
become comfortably familiar with the ECO content by the time you are finished with this book. 
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As you finish each chapter, review the Quicktest at the beginning of the chapter. Make sure you know the meaning 
of each concept. Use Hot Topics to improve recall and test your knowledge of each chapter. 

If possible, form a study group after you have read the book for the first time on your own. Your study time will be 
more effective. You will be able to discuss content together and the studying (and celebrating afterward) will be 
more fun. A study group should consist of only three or four people. (See How to Use This Book in a Study Group 
on page 25.) 


3. Skim through this book again, reviewing areas where you are not confident with the content. 


10. 


For these areas you reviewed because you had less confidence, answer a small sample of questions (no more than 
20) using the Focused Test function in PM FASTrack*. Analyze why you answered questions wrong and continue 
to study these gap areas. PM FASTrack* helps with this by allowing you to download a spreadsheet of the questions 
you got wrong. It is called “Export Analysis Data” in PM FASTrack*. 

When you feel you are prepared to do so, take a full exam simulation on PM FASTrack*. This step will give you a 
baseline against which to track your progress as you continue to study. 

WARNING: Limit yourself to no more than two full exam simulations before you take the actual exam. 
Otherwise, you diminish the value of PM FASTrack* by memorizing questions and answers that will not be 


presented in the same way on the exam. 


WARNING: If you do not score 70 percent or more the first time you take a full exam simulation (not just a 
shorter exam on a single content area or ECO domain), you may need a refresher in basic project management 
concepts. If you have taken a project management fundamentals class, review the materials you received from 
that class. If you have not had this class, consider taking one. Or you may need a PMP Prep class. Contact us 


using the information on rmcls.com/contact-us/. We can help assess your needs. 


Review each question you got wrong in PM FASTrack*, recording the specific reasons for each wrong answer. 
Assess why the correct choice is correct and why the other answers are wrong. In PM FASTrack*, we explain the 
answers and give references to help you quickly return to the related content. Use the “Export Analysis Data” 
within FASTrack to download a spreadsheet of questions you got wrong. 


Use your list of why you got each question wrong (from the previous step) to determine what to study further. This 
will help you determine how much more study time you need and which content areas to review more carefully. 
Continue to study this book, focusing on areas in which you have more gaps and skimming sections or chapters on 
which you did well. For chapters you need to review, always start by reviewing the Overview sections of the 
chapter, where we map the ECO to other PMI resources and point out important aspects of ECO domain tasks. 
And remember, think about good project management practices according to PMI as discussed in this book and 
based on approaches along the plan-driven, agile, and hybrid spectrum. Do this regardless of how you manage your 
projects in the real world. 

For the topic areas where you had the most trouble, review these again. Then you may want to answer a small 
sample of questions (no more than 20) using the Focused Test function in PM FASTrack*!. Analyze why you 
answered questions wrong and continue to study gap areas. 

WARNING: You might be tempted to answer more than 20 questions, but this should be sufficient to assess 
your progress in the particular content area and whether you need to study more. Answering more than 20 
questions in a particular area can diminish the value of PM FASTrack* and will not prepare you for the breadth 


of the exam experience. 


Take your second and final PMP simulation exam. You should score over 75 percent before you take the real exam. 


You are overusing PM FASTrack* if you see many repeated questions. 


Use Hot Topics and other materials to continue to review the content until you take the exam. 


. Create your test strategy (see the “Tips for Passing the PMP Exam the First Time” chapter). 
12. 


PASS THE EXAM! 
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Plan B: Using This Book As a Stand-Alone 
(PMP* Exam Prep book, RMC Resources, RMC Interactive Chapter Quizzes) 


Read this book for the first time and complete the exercises. Spend more time on the areas where you recognize you 


have knowledge or experience gaps; items you did not know or do prior to beginning this course of study. Refer to Rita’s 


Process Chart” and Ritas Agile Process Chart” frequently (included in chapter 3 of this book). Be sure you understand all 


the efforts involved in the topics you are working on. Use the ECO as we direct in each of the ECO domain chapters, to 


become comfortably familiar with the ECO content by the time you are finished with this book. 


1, 


2. 


As you finish each chapter, review the Quicktest at the beginning of the chapter. Make sure you know the meaning 
of each concept. 


If possible, form a study group after you have read the book for the first time on your own. Your study time will be 
more effective. You will be able to discuss content together and the studying (and celebrating afterward) will be 


more fun. A study group should consist of only three or four people. (See “How to Use This Book in a Study 
Group” on page 25.) 


3. Skim through this book again, reviewing areas where you are not confident with the content. 


9, 
10. 


Once you feel confident about the material, take the interactive RMC Interactive Chapter Quizzes in one sitting. 
This will give you a baseline to tell you how much you have learned. It will also help you determine how much 
additional study time you need and which chapters to read more carefully. 

Review each question you got wrong in RMC Interactive Chapter Quizzes, writing down the specific reasons for 
each wrong answer. Assess why the correct choice is correct and why the other answers are wrong. Review each 
question you got wrong in RMC Interactive Chapter Quizzes, recording the specific reasons for each wrong 
answer. Assess why the correct choice is correct and why the other answers are wrong. In RMC Interactive Chapter 
Quizzes, we explain the answers and give references to help you quickly return to the related content. RMC 
Interactive Chapter Quizzes help with this by allowing you to download a spreadsheet of the questions you got 
wrong (it is called “Export Analysis Data” within the RMC Interactive Chapter Quizzes tool). Continue to study 
this book, focusing on the areas in which you have gaps in your knowledge and skimming the sections or chapters 
on which you did well. 


. Correct any errors in your understanding of the concepts discussed in this book. 


WARNING: If you do not score 70 percent or more the first time you take the RMC Chapter Quizzes, you 
may need a refresher in basic project management concepts. If you have taken a project management 
fundamentals class, review the materials you received from that class. If you have not had this class, consider 
taking one. Or you may need a PMP* Prep class. Contact us using the information on rmcls.com/contact-us/. 
We can help assess your needs. 


Make sure you really know the material, and then retake the RMC Interactive Chapter Quizzes. As with step 5, use 
downloaded spreadsheet from the tool to identify the specific, not general, reason you got each question wrong. 
Use your list of why you got each question wrong (from the previous step) to determine what to study further. This 
will help you determine how much more study time you need and which content areas to review more carefully. 
Continue to study this book, focusing on areas in which you have more gaps and skimming sections or chapters on 
which you did well. For chapters you need to review, always start by reviewing the Overview sections of the 
chapter, where we map the ECO to other PMI resources and point out important aspects of ECO domain tasks. 
And remember, think about good project management practices according to PMI as we discuss in this book and 
based on approaches along the spectrum of plan-based, agile, and hybrid. Do this regardless of how you manage 
your projects in the real world. 
Create your test strategy (see the “Tips for Passing the PMP* Exam the First Time” chapter). 

PASS THE EXAM! 
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How to Use This Book in a Study Group 


To get started, pick someone to lead the discussion of each chapter (preferably someone who is not comfortable with the 
chapter, because the presenter often learns and retains the most in the group). Each time you meet, go over questions about 
topics you do not understand and review the hot topics on the exam using the Hot Topics flashcards ifyou have them. Most 
groups meet for one hour per chapter. Either independently or with your study group do further research on content you 
are not confident with questions you answered incorrectly in RMC Interactive Chapter Quizzes or PM FASTrack*. 

Each member of the study group should have their own copy of this book, which can be used within the group to 
make study and discussion commitments for group sessions. (Please note that it is a violation of international copyright 
laws to make copies of the material in this book or to create derivative works from this copyrighted book.) 
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Section II 


Foundations 


In this section, you will learn the foundations of project management. First, we will guide you through key PMI references 


and how they relate to the exam. Then, we will discuss predictive, hybrid, and adaptive approaches to project management. 


Youll find out how projects are selected and what the roles are on a project. Here are some highlights of this section: 


. 


Predictive and agile approach overviews 

Plan-based process groups: initiating, planning, executing, monitoring and controlling, and closing 
Agile processes: feasibility, initiation, release planning, iterations and product release, and closing 
Rita’s Process Chart (a valuable study tool when learning about plan-based projects) 

Rita’s Agile Process Chart (when learning about agile projects) 

How project management relates to the organization 

How projects are selected 

Project roles and responsibilities 


What integration means and how it is a key part of managing a project 
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2 PMP® Exam References 
in Context 


Introduction 


In this chapter we provide an overview of the Process Groups model for plan-driven (or predictive) 
project management, an agile model overview for adaptive project management, and an overview of 
possible hybrid models of project management. This chapter also explains the relationships between 
groups of concepts presented in this book, and what you need to know about these concepts for the 
exam. We provide an overview of PMI’s Examination Content Outline (ECO), the PMBOK* Guide, Sev- 
enth Edition, and Agile Practice Guide. While PMI says the exam is based on the ECO, our research tells 
us there are also questions on the exam based on content in these references. 

We will ask you to look at the ECO periodically in reference to something specific being discussed. 
If you have not yet downloaded a copy of the ECO from PMI’s website, do that now. It will be a good 
reference tool as you read this book. Feel free to refer to it as you complete exercises too. 

PMI publishes a copy of its suggested reference list on its website, and it is a long list of publica- 
tions. Does this mean you have to read all these books? No! The good news is that we have done the 
research for you and the information you need to pass the exam is in this book. We suggest that you 
obtain copies of the PMBOK* Guide, Seventh Edition, Process Groups: A Practice Guide, and Agile 
Practice Guide. If you have a PMI membership, you can access electronic copies of these books for no 
additional charge on PMI’s website. You can also purchase a hard-copy of the PMBOK* Guide on 
RMC’s website. 

You will not need to read these cover-to-cover. Instead, think of them as resource guides that you 
browse or open to a certain page to look up something specific. The most important information from 
each of those resources is summarized in this book. 


Definitions Related to Planning 

We will start with the following definitions to remind you, as you read this chapter and the rest of the 
book, that planning is iterative, regardless of what project life cycle and development approach you 
have selected with which to manage a project. 


Rolling Wave Planning and Progressive Elaboration 

Have you ever worked on a project that seemed to have too many unknown components to adequately 
break down the work and then schedule it? Or the project will have phases and it makes more sense to 
plan some later phases in detail at a later time? Even in a predictive environment, it is often better to 
not plan the entire project to the smallest detail in advance. Instead, it is sometimes better to just plan 
at a high level and then develop more detailed plans when the early project work is being done. This 
practice is called rolling wave planning. It is a form of progressive elaboration. 


Progressive elaboration refers to the process of clarifying and refining plans as the project 
progresses and more information becomes available. With this common tailoring method, you plan 
activities in the detail needed to manage the work just before you are ready to start that part of 
the project. 


Iterations of rolling wave planning during the project may result in additional activities being 
added, and in the further elaboration of other activities. Therefore, rolling wave planning may create 
the need for updates to the project management plan and other project artifacts. Since the earlier 
version of the project plan is usually already baselined, these changes often require formal change 
requests and integrated change control. 


QUICKTEST 


Rolling wave planning 
Progressive elaboration 
Examination Content 
Outline (ECO) 
- People 
- Process 
- Business Environment 
Process Group model 
- Initiating 
- Planning 
- Executing 
- Monitoring and 
Controlling 

- Closing 

Phase gates 

Rita's Process Chart™ 
Agile process 

- Feasibility 

- Initiation 

- Release Planning 

- Iteration 

- Close-out 

Rita's Agile Process 
Chart™ 

Personas 

Product release 
Hybrid project 
management 

Value delivery system 
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Examination Content Outline (ECO) Overview 


Hie Examination Content Outline (ECO) organizes the exam material into three performance domains: 

+ People 

e Process 

+ Business Environment 

Each domain lists a number of tasks, which taken together, summarize the responsibilities of a project manager within 
that domain. The order of the performance domains and the tasks within them are not important. In this book we organize 
the domains and tasks in terms of where they most make sense for what you need to know and what part of the project 
management process we are talking about. We include domain and task numbers to make it easy for you to find them in 
the ECO. 

The following overview will help you with a basic understanding of what the ECO includes. We will include specific 
content from it in proper context throughout this book. 

The domain names will not be tested on the exam but you should understand their tasks and enablers as they relate 
to managing projects in both adaptive and predictive environments. You can use the domains to manage your study time 
since PMI states that 42% of the exam is based on the People domain, 50% of the exam is based on the Process domain, 
and 8% of the exam is based on the Business Environment domain. As you study, identify your gaps in each domain so you 
can focus your time on filling those gaps before the exam. 


Domain |: People 
The People domain concerns skills and methods that help you succeed as a project manager and that you can use to help 


others succeed on projects. These include servant leadership, team building, motivation, and conflict management. We will 
focus on specific tasks listed in the ECO, appropriate to each of the following chapters. To start, here is a good list of 


“people skills” a successful project manager needs: 


+ Active listening e Facilitation + Personal integrity and 

+ Adaptive leadership * Individual trust building 

+ Coaching and mentoring performance evaluation * Rewards and 

e Collaboration + Negotiation recognition systems 

* Conflict resolution e Participatory decision making * Team performance evaluation 
+ Emotional intelligence * Team development e Understanding of motivation 


Domain II: Process 
The Process domain includes the technical project management skills, methods, and the activities needed to manage a 
project and deliver the benefits for which the project was undertaken. People work together in this effort—the project 
manager and team—so wouldn’t you expect to be using skills and abilities from the People domain? Of course! You lead 
the organization of the project and facilitate the development of its product with these skills alongside a balanced 
understanding of the business environment in which you are operating. 

The tasks in the Process domain involve managing many of the processes you have probably already handled in your 
experience as a project manager. They include the management of the following project management processes, along with 
the integration of all aspects of the project and other related tasks: 


+ Communications e Procurement * Scope 
+ Budget and Resources e Risk + Stakeholder engagement 
* Quality * Schedule 


Managing project governance, artifacts, issues, changes, the use and transfer of lessons learned, and product turnover 
to operations are also part of this domain. Once the project has been closed and turned over, a key measure of success is 
the continuation of the projects value and benefits (also part of the Business Environment domain). 
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Domain Ill: Business Environment 

Projects occur within the larger organization and business environment. Let’s say you have the skills associated with people 
and experience with project management processes. You also need to know how to navigate the internal and external 
business environments. You probably know this, but you may not have thought about it as a separate factor in your success. 

The presentation of the business environment as a separate ECO domain helps you focus on understanding the 
organization in which you work and the environment in which it does business. Understanding the business and 
environmental factors are critical to accomplishing project objectives for the betterment of your organization and its 
stakeholders. Let’s take as an example the task of evaluating and delivering project benefits. You can only accomplish this 
task if you use skills related to the People and Process domains together with a complete understanding ofyour organization’s 
culture, processes, and practices, and of the external, cultural, and legal environments in which they operate. 

As another example, let’s say that as part of renovating a library, the project manager plans to work with the city on 
enhancing transit options for getting to the library. Then they hear that a new highway interchange will be built nearby with 
a major transit hub included. This will affect the project in a number of ways. Organizations evaluate the external business 
environment during project selection. Then the project manager continuously monitors the business environment as they 
plan, execute, and control the project to ensure that environmental changes do not negatively affect project objectives. 


The Process Groups Model Overview 


PMI recently released its Process Groups: A Practice Guide, to explain its Process Groups model. The Process Groups model 
content originated in previous editions of the PMBOK* Guide, so it is familiar to many project managers that have used 
previous editions of the PMBOK* Guide. 

The Process Groups model describes a prescriptive or plan-driven approach to project management. Much of the 
information in the Process Groups model can be used as a learning model for project management in general. It is with 
good reason that the Process Groups model is so widely used today, and that we include it in this book. It is a good and 
comprehensive model for prescriptive project management. In addition, over many years, through PMI’s propagation of it 
in previous editions of the PMBOK* Guide, organizations throughout the world have adopted it and tailored it to their own 
needs. So many thousands of project managers are familiar with some form of this model. More important yet: 
Understanding it will greatly enhance your ability to answer many of the 50% of questions based in predictive environ- 
ments. In addition, this model is useful in many hybrid project management approaches across the approach spectrum. For 
these reasons we use it extensively in this book as a learning model. 


Process Groups 
The Process Groups model starts with five process groups that in a general way describe how a project is managed, from 
beginning to end. These process groups are: 

+ Initiating 

+ Planning 

+ Executing 

* Monitoring and Controlling 

* Closing 

For now, you may draw the conclusion that to manage a project you would follow the process groups from initiating 
to planning, executing, monitoring and controlling, to closing, one after the other, from the beginning to the end of the 
project. You would be right—but only partly right. While the process groups generally lead you in order from the beginning 
to the end of a project, at the same time you carry out the activities associated with them in a very dynamic fashion, 
sometimes going back and forth between the process groups. 

The real story is that project management is a very dynamic process that cannot be adequately described as a linear 
progression through these processes, although understanding its linear progression is useful. The process groups order the 
progression through a project. But at the same time, an activity belonging to one process group might cause a return to an 
“earlier” process group to respond to a request, carry out an activity, or solve a problem. 
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Understand the rest of this section and you will be well positioned to understand the Process Groups model and the 
processes within it, as we explain them further, especially in the Process domain section of this book. You will also 
understand how everything fits together to help you manage plan-driven projects successfully—and, of course, to answer 
related questions on the exam. 

Figure 2.1 shows generally how the five process groups interact on a project. You have the overall initiating effort, 
followed by planning. Notice the double-arrows between planning, executing (where we are building the product), and 
monitoring and controlling (where we are observing and assessing activities to keep things on track). These double arrows 
are meant to indicate the dynamic, non-linear nature of much of project management work. For example, something that 
happens in executing and monitoring and controlling, like a change in product scope, may send you back to planning in 


order to replan to accommodate that change. Many changes like this occur on projects after initial planning is “complete. 


Now notice two more important things about figure 2.1. First, there’s a dotted line representing the directional arrow 
going from monitoring and controlling, back to initiating. This broken arrow is there to remind you that returning to 
initiating is not a given. In fact, once you leave initiating, it is only under limited circumstances that you would return to 
initiating. See figure 2.6, where we show those limited circumstances to you. 

The second important thing to note right now is that there are two components in figure 2.1 representing “M&C,” or 
monitoring and controlling. The M&C inside the smaller circle represents monitoring and controlling as a process you 
carry out along with the others, roughly following the start of executing. The larger, shaded circle also labeled M&C 


signifies that you are monitoring and controlling throughout the project. No matter what other activities you are carrying 


out, from whatever process groups, you should also be monitoring and controlling the situation. 


Key: 
|= Initiating 
P = Planning 
E = Executing 

M8C = Monitoring & controlling 
© = Closing 


FIGURE 2.1 Project management process 


Research Design Build Inspect Move-in Ready The five process groups interact with the selected 
fi J 


project life cycle, shown at the top of figure 2.2. Small 


projects following a plan-driven life cycle may be 
completed after going through all the process groups 
(initiating through closing) once for the entire project, 
although portions of the processes may be iterated or 
repeated throughout the project life cycle as shown in 
figure 2.2. 

Large projects often require the project manager 
to manage each life cycle phase iteratively through the 


project management process groups. 
FIGURE 2.2 Small project with a predictive life cycle 


The example illustrated in figure 2.3 is for a large construction project. In this large project, the development life cycle 
phases of feasibility, planning, design, construction, and turnover are all extensive, requiring revisiting the five process 
groups for each phase. For example, there would be an overall initiating effort in which the project manager helps create a 


charter and does high-level planning for the entire project to get charter approval. Then, a separate initiating process for the 
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feasibility phase would take place, followed by a planning effort for that phase, the execution and control of that work, and, 
finally, a closeout of the phase, which typically includes a handoff of deliverables—in this case, the results of the feasibility 
analysis. This would be repeated for each life cycle phase. 


FIGURE 2.3 Large project with a plan-driven approach and phase gates (indicated by the vertical bars) 


Phase Gates At the end of each phase, an event called a phase gate may take place. A phase gate involves analyzing the 
results of the completed phase against what was planned for that phase. Based on that analysis, options may include redoing 
the same phase, moving forward with the next phase, or choosing not to continue with the project. If the decision is made 
to move forward, the project would begin initiating work on the next phase and progress through the project management 
process groups for that phase. 

Projects may also be broken into phases and then into smaller releases and iterations within those phases. The project 
management processes of initiating, planning, executing, monitoring and controlling, and closing are done for each phase. 
The level of detail and the time spent on each process group may vary, but the entire project management process is 
typically followed, as indicated in figure 2.4, which depicts the plan-driven process groups with an agile approach. This 
could be a project using a strictly agile approach, or a hybrid project using project management methods from both plan- 
driven and agile approaches. 


FIGURE 2.4 Large project with an agile approach 


TRICKS Agile approaches usually don’t include the use of the term “phase.” The traditional “phase gate” system is 
OF THE different from an adaptive environment where iterations tend to be short and include product reviews (demos) 
TRADE@ and retrospectives. The overall process is usually more flexible and evolves throughout the project. 


TRICKS Looking at figure 2.4 again, where in the life cycle do you think are opportunities for using a hybrid approach? 
OF THE While the entire life cycle may look adaptive, at the “release” level you can see an iterative approach is most 
obvious. It’s most likely during feasibility, initiation, release planning, and close-out that you’d weave in 
predictive elements if you chose to do so. 


The illustration that appeared in figure 2.1 is shown again here in figure 2.5 for your reference as you read the rest of 
this section and continue to understand the project management process through the process groups. 
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Start Here: Take time to fully understand figure 2.5 
before continuing. 


Arrows move clockwise from Initiating (I). The 
process moves mostly in order from Initiating 
(I) through Planning (P), Executing (E), 
Monitoring & Controlling (M&C), and Closing 
©. 

Double arrows between Planning (P), 
Executing (E), and Monitoring and 
Controlling (M&C) process groups show that 
you often move back and forth between them as 
you tailor to events taking place. New 
information becoming available in executing 
(E) may return you to planning (P). 

The single dotted arrow returning from 
monitoring and controlling (M&C) to initiating 
(69) indicates that only under limited 
circumstances you may enter initiating once 
you leave it (see figure 2.6). 


Two 


M&C = Monitoring & controlling 
C = Closing 


FIGURE 2.5 Project management process 


Keep in mind that monitoring and controlling is carried out from start to finish on the project. Remember for the exam: 
Work in all other process groups takes place in the context of ongoing monitoring and controlling. 


The following figures illustrate the reasons for entering the various process groups. Remember, project management 
is not linear. For example, project planning can be entered into because the results of project monitoring and controlling 
necessitates additional planning. 


Project 


initiating 


FIGURE 2.6 Reasons for entering project initiating 


FIGURE 2.7 Reasons for entering project planning 
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Project Project 


executing closing 


FIGURE 2.8 Reasons for entering project executing FIGURE 2.9 Reasons for entering project closing 


Let’s stop here for a moment to talk about the executing process in a predictive environment versus an 
adaptive environment. The plan-driven approach to executing is to “go do the items identified in the project 
plan” and update the project plan baseline if changes occur. These changes may be necessary due to 
unanticipated issues and risks in activity durations and resource productivity or availability, or for other 
reasons. We assume that to a certain extent planned activities are fully understood prior to starting work and 
are completed according to the plan, even though that is not always the case. 

Agile methods employ an executing approach in which additional efforts may be made to replan some or all of a 
project. This is due to the nature of projects that may require a lot of change because project and product scope are 
emerging. We assume all aspects of work are not known in advance and learning with adaptation will be necessary to 
complete the project, either because of technical uncertainty or changes to requirements. 


We are showing you monitoring and controlling last because its relationships to the other process groups are more 
intricate. Think about these relationships as you study for the exam. Many students struggle to define what happens during 
monitoring and controlling versus other process groups, especially executing. Figure 2.10 illustrates key project outputs 
(on the left) that trigger a focus on monitoring and controlling. It also shows (on the right) that you may tailor your 
processes to go from monitoring and controlling to any of the other process groups, depending on the situation. 


Project 
monitorin 
and controlling 


FIGURE 2.10 Key outputs that trigger monitoring and controlling, and potential next steps 
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One reason test takers often find monitoring and controlling to be particularly challenging is that you are expected to 
know how to observe, measure, evaluate, and analyze a project in a more complete and systematic way than many project 
managers have experience with. 

Monitoring and controlling applies to both agile and plan-driven projects. However, it is useful to think 
in terms of plan-driven approaches to understand the work of this process group for now because agile 
practitioners tend not to use the language associated with the five process groups, like “monitoring and Agile 
controlling.” Nevertheless, just as plan-driven project managers and teams do, agile practitioners measure ie 
project and team performance as the product is being built. They also adjust the plan or their actions to remain in line with 
the plan, as needed. 

Agile approaches use different techniques for controlling, with more demos and feedback rather than tests to 
specification, but the goal of adjusting the product and processes as needed is the same. These environments, which have 
a high amount of change, usually handle evaluating and approving project changes through the role of a product owner. By 
putting the product owner in charge of the backlog, an agile team delegates the authority for local decision making to this 
team member to streamline the change control process. 

The iteration review and the retrospective that follow an agile iteration are indicative of the experimental and learn- 
as-we-go nature of agile projects. These are “measure and control” efforts although the term “monitoring and control” is 
not used. Special iterations (sometimes called spikes) can be created specifically to try new technology or test new process 
changes. These short cycles provide important feedback on what is working and what needs further tuning. 


Project Constraints and Other Management Areas 

You will see a lot of discussion in this book about both the ECO and the Process Groups model. Both represent the 
processes you are managing in project management. Figure 2.11 compares the main content of the ECO Process domain 
with that of the Process Groups model, with a symbol between them illustrating their rough equivalence as we have 
mapped it. Take a moment now to open your ECO so you may read the integration-associated tasks. 


ECO Process Tasks (Domain I!) Process Groups Model 


e anven memes pisces 


Scope Management 
Schedule Management 
Cost Management 
Resource Management 
Quality Management 
Communications Management 
Risk Management 
Procurement Management 


Stakeholder Engagement 


Note: The “budget and resources” Process domain task is comparable to costand resource management 
in the Process Groups model. “Human resources” (or soft) skills are addressed in the People domain. 


FIGURE 2.11 Relationship between ECO Process domain and Process Groups model I b 
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Rita’s Process Chart™: A Vital Study Tool 


We are here to help you really learn plan-driven project management with the Process Groups model! Since the first edition 
of this book, people all over the world have used Rita’s Process Chart™ as a tool to learn this project management process 
in detail, quickly and effectively. Once you understand it, you can use Rita’s Process Chart™ to initiate, plan, and run a 
plan-driven project, and many of its concepts can also be applied on agile and hybrid projects. 

On the exam, although you may not have to identify specific process names from Process Groups: A Practice Guide, 
knowing where you are in the project management process when you read a question’s scenario will help you get the 


right answer. 


How to Use Rita’s Process Chart™ 

Located on page 38, Rita’s Process Chart’s™ function is to state, simply and directly, the efforts involved in managing a 
project. Understanding these efforts will provide the context you need for the exam. 

As you review Rita’s Process Chart™, make sure you: 

* Understand the overall project management process. 

+ Find terms you do not know and learn what they are by looking them up in this book. 

* Know why each item is in the column (process group) it falls into. 

e Understand the project management process groups of initiating through closing, including when each effort should 
be done on projects. The exam asks questions that present a situation and require you to know where you are in the 
project management process. 

e Can replicate the specific order of the planning activities by understanding what happens when, how previous work 
supports what comes next and why. Use Ritas Process Chart™ Game (discussed later in this chapter) for this. 
Knowing Rita’s Planning column in this order can help you get a large number of questions right on the exam because 
the exam often asks what should be done next. The work in the other process groups does not have a set order. 

* Understand that project planning is an iterative process. Consider how you might go back and redo (iterate) some of 
the items in the Planning column to refine the plan. Think about how rolling wave planning (a form of progressive 
elaboration) would be used on a large project to refine and detail plans for each phase as you move through the project 
life cycle. Here, the earliest parts of the project are planned in sufficient detail for work to begin. Later phases of work 
are planned at a high level. As the project progresses, and more information impacting the work becomes available, 
plans are elaborated in sufficient detail to accomplish the work. 

* Complete Rita’s Process Chart™ Game at least three times. Repeating the game will re-enforce your understanding 
of the overall project management process and help you find your knowledge gaps. Focus your study on your gap areas 


so you fill those gaps before taking the exam. 
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Rita’s Process Chart™ 


Select project manager 


Determine company culture 
and existing systems 


TWO 


Collect processes, procedures, 
and historical information 


Determine development 
approach, life cycle, and 
how you will plan for each 
knowledge area 


Execute work according to the 
project management plan 


Produce product deliverables 
(product scope) 


Take action to monitor and 
control the project 


Confirm work is done to 
requirements 


Divide large projects into 
phases or smaller projects 


Define and prioritize 
requirements 


Gather work performance data 


Request changes 


Measure performance against 
performance measurement 
baseline 


Complete final procurement 
closure 


Gain final acceptance of 
product 


Understand business case and 
benefits management plan 


Create project scope statement 


Uncover initial requirements, 
assumptions, risks, constraints, 
and existing agreements 


Assess what to purchase and 
create procurement documents 


Implement only approved 
changes 


Measure performance against 
other metrics in the project 
management plan 


Complete financial closure 


Hand off completed product 


Determine planning team 


Continuously improve; 
perform progressive 
elaboration 


Analyze and evaluate data and 
performance 


Solicit customer's feedback 
about the project 


Assess project and product 
feasibility within the given 
constraints 


Create WBS and WBS 
dictionary 


Follow processes 


Create measurable objectives 
and success criteria 


Create activity list 


Create network diagram 


Determine whether quality 
plan and processes are correct 
and effective 


Determine if variances warrant 
a corrective action or other 
change request(s) 


Complete final performance 
reporting 


Influence factors that cause 
change 


Index and archive records 


Develop project charter 


Estimate resource requirements 


Perform quality audits and 
issue quality reports 


Request changes 


Gather final lessons learned 
and update knowledge bases 


Identify stakeholders and 
determine their expectations, 
interest, influence, and impact 


Estimate activity durations 
and costs 


Acquire final team and physical 
resources 


Perform integrated change 
control 


Determine critical path 


Manage people 


Approve or reject changes 


Request changes 


Develop schedule 


Develop assumption log 


Develop budget 


Evaluate team and individual 
performance; provide training 


Update project management 
plan and project documents 


Develop stakeholder register 


Determine quality standards, 
processes, and metrics 


Hold team-building activities 


Inform stakeholders of all 
change request results 


Give recognition and rewards 


Determine team charter and all 
roles and responsibilities 


Use issue logs 


Monitor stakeholder 
engagement 


Plan communications and 
stakeholder engagement 


Facilitate conflict resolution 


Confirm configuration 
compliance 


Perform risk identification, 
qualitative and quantitative 
risk analysis, and risk response 
planning 


Release resources as work is 
completed 


Create forecasts 


Send and receive information, 
and solicit feedback 


Gain customers acceptance of 


interim deliverables 


Go back— iterations 


Finalize procurement strategy 
and documents 


Report on project performance 


Facilitate stakeholder 
engagement and manage 
expectations 


Perform quality control 


Perform risk reviews, 
reassessments, and audits 


Manage reserves 


Create change and 
configuration management 
plans 


Hold meetings 


Finalize all management plans 


Evaluate sellers; negotiate and 
contract with sellers 


Manage, evaluate, and close 
procurements 


Develop realistic and sufficient 
project management plan and 
baselines 


Use and share project 
knowledge 


Evaluate use of physical 
resources 


Execute contingency plans 


Gain formal approval of the 
plan 


Update project management 
plan and project documents 


Hold kickoff meeting 


Request changes 
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Study Notes for Rita’s Process Chart™ 


Remember while this focuses primarily on plan-driven project management, many of the same concepts apply to agile 


projects as well. We continue to note the differences throughout the book. 


INITIATING 


Select project manager 


Determine company culture and 
existing systems 


Collect processes, procedures, 
and historical information 


Divide large projects into phases 
or smaller projects 


Understand business case and 
benefits management plan 


Uncover initial requirements, 
assumptions, risks, constraints, 
and existing agreements 


Assess project and product 
feasibility within the given 
constraints 


Create measurable objectives 
and success criteria 


Develop project charter 


Identify stakeholders and 
determine their expectations, 
interest, influence, and impact 


Request changes 


Develop assumption log 


Develop stakeholder register 


Initiating 


* You will read more about project selection in the following “Foundations” 
chapter of this book. Does it matter for you to know why your project was 
selected? Yes, of course. It will influence how you plan the project, what kinds of 
changes are allowed, and how the project scope is defined. The business case and 
the benefits management plan are inputs to developing the project charter (and 
the project charter is covered in more detail in the Integration chapter of the 
Domain II: Process section of this book.) 

e Notice the phrase “Understand business case and benefits management plan.” 
This could be read as “Understand the reason the project is being done and the 
benefits the organization expects to gain as a result of it.” These business 
documents are created before the project begins and contribute to the project 
being selected by the organization among many project proposals. They will 
guide all project management activities to ensure the project is worth the 
investment and that it will return the expected benefits to the organization. 

This is an exam concept that many project managers miss. As the project 
manager, you should understand why your project was selected and what benefits it 
is expected to deliver. Is the project being done so the organization can enter a new 
market? Is it intended to meet a regulatory requirement? Is it the result of a 
customer request? Is it a priority project for a company executive? Is it expected to 
dramatically improve the future of the company? If you lose sight of objectives, the 
project may finish on schedule and on budget but still fail because it does not 
achieve its objectives or does not deliver the expected value. 

* Team building, risk identification, stakeholder identification, risk response 


planning, and many other activities primarily occur in the process groups in 
which they are placed on the chart, but these activities can start in initiating and 
continue until closing. 

* Identifying and analyzing stakeholders help to align their expectations about the 
project and assess their potential involvement and influence on the project. 

* The project manager determines whether the project objectives can be achieved 
and if it is likely to be completed within the given constraints. High-level planning 
is summarized in a project charter, which documents high-level estimates, 
measurable objectives, success criteria, milestones, and an initial budget. Initial 
planning may also include creating a high-level WBS and high-level risk 
identification. 

* The charter, once formally approved by the sponsor, gives the project manager 
the authority to continue the project beyond initiating. It also provides a guiding 
vision of the project’s business case and benefits management plan, and the 
organizations strategic objectives. 

* Besides an approved project charter, an artifact of initiating is the stakeholder 
register. Then, detailed planning can begin. 
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PLANNING 
(This is the only process group 
with a set order.) 


| Determine development 


approach, life cycle, and how you 
will plan for each knowledge area 


Define and prioritize 


| requirements 


Create project scope statement 


Assess what to purchase and 
create procurement documents 


Determine planning team 


Create WBS and WBS dictionary 


Create activity list 


Create network diagram 


Estimate resource requirements 


Estimate activity durations and 
costs 


Determine critical path 


Develop schedule 


Develop budget 


Determine quality standards, 
processes, and metrics 


Derermlne team charter and all 
roles and responsibilities 


Plan communications and 
stakeholder engagement 


Perform risk identification, 
qualitative and quantitative 
risk analysis, and risk response 
planning 


Go back— iterations 


Finalize procurement strategy 
and documents 


Create change and configuration 
management plans 


Finalize all management plans 


Develop realistic and sufficient 
project management plan and 
baselines 


Gain formal approval of the plan 


Hold kickoff meeting 


Request changes 


TWO 


Planning 


In the planning column, note the first box: “Determine development approach, life 
cycle, and how you will plan for each knowledge area.” In plan-driven approaches, 
each knowledge area (scope, schedule, cost, etc.) requires a management plan. 
Additional plans are needed for configuration (or updating of project artifacts), 
change, and requirements management. The first thing you need to do is figure out 
how you will plan, execute, and control for each knowledge area. This will guide the 
rest of your planning efforts. 

The project manager and team perform a detailed analysis of whether the objectives 
in the project charter and the expected business benefits can be achieved. They 
determine what processes are appropriate for the needs of the project and tailor 
processes to those needs. 


Notice the phrase “Determine team charter and all roles and responsibilities.” 
Determining roles and responsibilities involves determining who is going to do 
which product-related work activities but also who will provide reports, attend 
meetings, help with risk identification, work with the quality department, etc. Roles 
and responsibilities may be documented as part of the resource management plan, 
in project job descriptions, or in the management plans for each area. This item may 
also include developing a responsibility assignment matrix (RAM) and a rewards 
and recognition system. 

Some projects may be organized by phases where detailed planning for the next 
phase is started as the previous phase nears completion. In agile planning only the 
first part of the project may be fully planned, while the later portions are planned at 
a high level and then progressively elaborated when more is information about the 
project becomes available. 

Remember when we said project management seems linear but is dynamic? The 
Planning column has a reminder that planning is the only process group with a set 
order. However, a planning process may require an input that isn’t available yet. The 
tisk register, for example, is an input to several processes leading to the creation of 
the schedule. Initial risks are documented in the charter, so although the risk 
register will by no means be complete when the schedule is created, known risks 
can be factored into planning. Then, after performing risk management activities, 
the more complete risk register can be used to refine the schedule. 

Look at the phrase “Go back— iterations.” This is an important concept. Planning is 
iterative. When planning a project, the project manager and the team complete each 
item listed above this point to the best of their ability. But even a plan-driven project 
will evolve as the project progresses and earlier planning work is then modified. For 
example, it is only after completing risk management planning that the WBS and 
the other items can be finalized. A risk response strategy may be used to avoid a 
portion or all of a threat (see the “Risks and Issues” chapter). This will require 
adjusting the WBS for added scope (the risk response plans), the network diagram 
to redetermine the order of the work, the budget for added cost, and so on. The 
project manager might also work with discretionary dependencies to change the 
network diagram and thereby decrease some risk (see the “Schedule” chapter). 
Notice the term “procurement strategy and documents” in the Planning column. 
Also note the placement of “Finalize procurement strategy and documents” after 
“Go back—iterations.” The risk management process may generate risk response 
strategies involving contracts; through iterations the procurement documents can 

be created, refined, and finalized. 
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+ The important thing to remember is that planning should lead to a realistic, bought-into, approved, and formal project 
management plan that is updated throughout the project to reflect approved changes. 


+ The distinction between predictive and adaptive approaches is worth thinking about here. The Process Groups: A 
Practice Guide planning processes describe all the traditional activities performed to define the total scope and courses 
of action for a project. It assumes that with sufficient analysis these are knowable, and development is then largely the 
execution of this course of action. Progressive elaboration and rolling wave planning are effective mechanisms to tune 
plans to emerging details, and they act as accepted adjustments to detailed initial planning. 

+ Although the project management plan is “finalized” in planning, items such as detailed estimates and product and 
project scope descriptions may be modified as the work is being done during the executing and monitoring and 
controlling processes. 

+ The project management plan and documents (also known as project artifacts) resulting from planning guide the 
execution and control of the project. After the plan is iterated and includes the appropriate detail for the project life 
cycle and development approach, the sponsor approves it. 

Rolling wave planning and progressive elaboration exist within the predictive framework of project management as 

supporting elements. Agile planning is deliberately more incremental and iterates to discover and refine scope, making 
progressive elaboration a central rather than a supporting element. 
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EXECUTING 


Execute work according to the project management plan 


Produce product deliverables (product scope) 


Gather work performance data 


Request changes 


Implement only approved changes 


Continuously improve; perform progressive elaboration 


Follow processes 


Determine whether quality plan and processes are correct 
and effective 


Perform quality audits and issue quality reports 


Acquire final team and physical resources 


Manage people 


Evaluate team and individual performance; provide training 


Hold team-building activities 


Give recognition and rewards 


Use issue logs 


Facilitate conflict resolution 


Release resources as work is completed 


Send and receive information, and solicit feedback 


Report on project performance 


Facilitate stakeholder engagement and manage expectations 


Hold meetings 


Evaluate sellers; negotiate and contract with sellers 


Use and share project knowledge 


Execute contingency plans 


Update project management plan and project documents 


TWO 


Executing 


With an approved project management plan, the project 
moves into executing, where the team completes the 
work according to the plan. The project manager’s focus 
is on leading people and managing the project, 
including engaging stakeholders, working with the team, 
following processes, and communicating according to 
the plan. For the exam, get your mind around the 
critical difference appropriate planning makes. Assume 
the project was properly planned before work began 
unless the question indicates otherwise. 

The purpose of project executing is to complete the 
project work as defined in the plan, to produce the 
project deliverables (the product scope) at agreed 
quality levels, within the project's approved budget and 
schedule. This achieves the expected business value and 
agreed-upon benefits. 

Team members can be released at any time once their 
work is approved and accepted and they have completed 
their project activities. 

Example Electricians on a project to build a house 
may test their work, get acceptance of their work, 
document lessons learned, suggest process 
improvements, and turn the work over. They are released 
while other team members doing drywall are still 
working. Some team members remain on the project to 
its end to assist the project manager in creating the final 
lessons learned, archiving final records, and producing the 
final report. 

As executing progresses, the project manager may 
determine that a change is needed. The same could 
happen while the project manager is monitoring and 
controlling the work, or in planning as a result of rolling 
wave planning that occurs after the plan has been 
approved and work has started. Change requests are 
evaluated and approved or rejected as part of the 


Perform Integrated Change Control process (see the 


“Integration” chapter). 
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MONITORING & Monitoring and Controlling 


CONTROLLING 


Take action to monitor and control 
the project 


Measure performance against 
performance measurement 
baseline 

Measure performance against 
other metrics in the project 
management plan 


Analyze and evaluate data and 
performance 


Determine if variances warrant a 
corrective action or other change 
request(s) 


Influence factors that cause change 


Request changes 


Perform integrated change control 


Approve or reject changes 


Update project management plan 
and project documents 


Inform stakeholders of all change 
request results 


Monitor stakeholder engagement 


Confirm configuration compliante 


Create forecasts 


Gain customer s acceptance of 
interim deliverables 


Perform quality control 


Perform risk reviews, 
reassessments, and audits 


Manage reserves 


Manage, evaluate, and close 
procurements 


Evaluate use of physical mesourcks 


Do the project management process groups occur sequentially? Yes, in a sense, 
but the paradox is that they overlap. For example, you could be using monitoring 
and controlling processes to control stakeholder identification and adherence to 
organizational requirements while project planning and the creation of baselines 
and project documents. Defects could be identified in executing that require 
work in monitoring and controlling to decide if the defects require a change to 
the plan to prevent future rework or delays as well as work in executing to fix 
them. Controlling procurements and the closure of procurements can occur 
simultaneously on projects because some sellers will complete their contractual 
obligations to the project while others are still producing deliverables. Look 
again at Rita’s Process Chart™ and think about the overall focus of each 
process group, but also about how the work can overlap at various points in 
time. 

While the work is being done, work results (or data) are fed into monitoring and 
controlling to make sure the project is advancing according to the established 
baselines. This requires evaluating hard data on how the project is conforming to 
the plan, and taking action to address variances that are outside of acceptable 
limits. The project manager and team are also assessing how stakeholders are 
participating, communicating, and feeling about the project and the work, and 
addressing uncertainties (or risks) that have been identified. 

The project management plan includes monitoring activities, such as observing, 
communicating, and evaluating. It also specifies control activities along with a 
plan for how variations from planned metrics should be addressed. 

Outcomes of monitoring and controlling include recommended changes to the 
way the work is being done or possibly requesting adjustments to baselines to 
reflect more achievable outcomes. Change requests are evaluated in Integrated 


Change Control to determine their impact on the project, identify the best 
options for dealing with them, and decide whether they should be approved, 
rejected, or deferred. 

Approved changes that require adjustments to baselines and other plan elements 
require replanning before the team starts working on them (in executing). If the 
project gets so far off the baselines that it requires an analysis of whether it 
should continue at all, or if significant changes are suggested that are outside the 
project charter, it may move back into initiating while that evaluation is done. 
Executing and monitoring and controlling actions continually overlap while the 
work of the project is ongoing, including keeping all project artifacts up-to-date. 
The focus for the project manager in executing is leading people, removing 
impediments to progress, and managing physical resources to accomplish the 
project as planned. The focus of monitoring and controlling is ensuring the 
project is progressing according to plan and approving necessary changes to the 
plan to meet the organizations strategic objectives and deliver the expected 


benefits. 
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CLOSING Closing 


+ The closing efforts are similar for plan-driven and agile projects. They 


Confirm work is done to requirements 


include collecting and finalizing all the artifacts needed to complete the 


Complete final procurement closure J project, and technical and administrative work to confirm that the final 
product of the project is accepted. They also include transferring the 


Gain final acceptance of product 


completed product to those who will use it and soliciting feedback from 


Ci lete fi ial cl n 
EA SEA —_]} the customer about the product and the project. 


Hand off completed product j * Lessons learned should be collected on an ongoing basis on plan-based 


Solisikcustomerts Tedak thë project projects and on agile projects after every iteration. They are finalized at 


closing. In both cases they should be put to use right away and after 


Complete final performance reporting 


closing be made available to future projects. 


Index and archive records + In many real-world situations, projects never seem to officially finish. 
Gather final lessons learned and update Keep in mind that all projects must complete the required 
knowledge bases closing activities. 


Rita’s Process Chart™ Game 


Our students invariably report that Rita’s Process Chart " and the associated explanations have been instrumental for 
them to pass the exam. The Rita’s Process Chart°™ Game has helped thousands of students remember and ensure their 
understanding of the overall project management process. You may at first find this game overwhelming, so just play it once 
before you finish reading this book. Then, come back to the game and play it a few more times before the exam and you will 
find it getting easier as you are better prepared. 

There are two formats you can use to play this game. 

+ An online version of Rita’s Process Char" Game is available at 


rmels.com/process-chart-game-vll. 


+ A printable version of the game is available for download. This version is available on our RMC 
Resources page: rmcls.com/rmc-resources (or scan the QR code). You can then cut apart the 


component “cards” and play the game using this high-touch, low tech format. 


RMC RESOURCES 


Agile Process Overview 


The Rita’s Agile Process Chart ” is a matrix representing an agile approach to project management. We draw 
comparisons between agile, plan-driven and hybrid approaches throughout the book so as you study you 
should become familiar with how both predictive and adaptive environments work. In addition, always keep Agile 
in mind that as a project manager you always tailor the methods you use to the needs of the project, and that Focus 


hybrid approaches work on some projects. 
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FEASIBILITY 


INITIATION 


TWO 


RELEASE 


Project visioning takes place 


Develop project charter 


PLANNING 


ITERATION 
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CLOSE-OUT 


Perform iteration planning 


Obtain final release approval 


Establish business case 


Create team charter 


Slice user stories 
(decompose features) 


Create high-level user stories 
(features) 


Establish high-level 
estimates 


Feasibility 


Build a release plan 


Hold daily standup meetings 


Create personas 


Identify stakeholders and 


contact 
Create backlog of features 


Create high-level estimates 


using affinity estimating 


Create product roadmap 


using story maps 


Remove impediments for 
the team 


Build features as described 
in user stories 


Build a release plan 


Build a release map 


J| Hold daily standup meetings 


Perform story estimation 
using Planning Poker* 


Focus on how to deliver 
value 


Define “done” 


Estimate how much work 
can be done 


Calculate team velocity 


Hold daily standup meetings 


Remove impediments for 
the team 


Turn over maintenance of 
product release to another 
team | 


Hold final retrospective 


Ensure procurement closure 


Update bumup charts 


Archive project artifacts 


Reprioritize the backlog 


Define the first iteration goal 


Ensure there is shared 
understanding among team 
members 


Prepare stories of next 
iteration 


Remove impediments for 
the team 


Identify acceptance tests for 
stories 


Prepare acceptance tests 
Run exploratory tests 


Test user stories 


Hold iteration review 


Hold retrospective 


Prepare stories of next 
iteration 

Collaborate with team to 
answer questions and obtain 


story signoff 


Agile teams are stable over time so projects are brought to the teams. There typically is not a new team assembled for each 
project, as is often the case with plan-driven project. Feasibility consists of the following. 


+ Establishing a business case often involves management and includes things like cost-benefits analysis, calculating 
expected return on investment and using other metrics to ensure that the project will create the desired value for the 


organization and its stakeholders. 


* Creating a product and project vision is an exercise where the team develops an “elevator pitch” or short statement 
describing the project and its product, benefits, and value in the time a ride in an elevator might take. 


e High-level features are documented along with very high-level estimates of the costs and other resources needed to 
create the product of the project. The features are very general descriptions of what will be needed from the product. 


Initiation 


At the point of initiating, you can assume feasibility studies and project selection are complete, just as you would when you 


are given a plan-driven project. The team develops the following: 


+ A project charter This is a high-level summary of the project and its scope, requirements, risks and other broad 
features of the project and product as known. The team charter is a set of agreements about how the team will commit 
to working together to communicate, build the product, and meet the needs of the project and each other. If the team 


already has a team charter, they will tailor it to the needs of the project. 


AS 
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e Personas These are profiles of the various types of stakeholders who will use the product. The team develops them 
to understand requirements from the perspectives of their various stakeholders, usually end users of the product. The 
team also identifies specific stakeholders and stakeholder groups, gathers their contact information, and begins to 
contact them. See figure 2.12. 

+ A product backlog This is an elaboration of the feature list started in Feasibility. This single artifact holds all the 
features needed from the product. It is elaborated and decomposed iteratively throughout the project. The team 
completes affinity estimation, or grouping features by high-level estimates of their size (estimated effort to build, for 
example small, medium, large, extra-large). Common terms used here are “bucket size” or “t-shirt size.” See figure 2.13 

+ A product roadmap (or story map) This graphic depicts features that will be built first, and then next, etc., across 
a period of time. Product increments are built and delivered to the customer in releases, so the product roadmap or 
story map may also be referred to as a release map. See figure 2.14. 


Remember that the product owner is an integral part of the team and helps in all these endeavors. The project manager 
meanwhile is ensuring that processes are understood and being followed, and is working to remove impediments to the 


team’s progress. 


Jemelia Job Seeker 


Description Values 
+ Looking for new job after completing + Free access to computer with easy apps 
bachelor’s degree in nursing « Free internet access 
+ Working as a home health aide + Easy instructions on the application 
* Does not have a computer for finding jobs process and how to access job boards 


* Needs access to job resources at odd 
hours during time off 


FIGURE 2.12 Example persona for library case 


# Backlog Item Stakeholders 


Pl Manage appointments Patients, administrators, practitioners 
P2 Change personal data and preferences Patients, administrators, practitioners 
P3 View health information library Patients, practitioners 

P4 Outreach (marketing) campaigns Patients, marketing 

P5 Practitioner and patient communications Patients, practitioners, marketing 

P6 Regulation compliance Patients, government 

P7 View patient’s own medical data from The Center Patients, administrators, practitioners 


FIGURE 2.13 Example partial backlog for clinic user website 
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Release 1 (Mar 28) Release 2 (May 30) Release 3 (Jul 31) 
- Regulation compliance - Regulation compliance - Manage bill and payments 
- Branding/style schemes - UID - Manage own insur- 
- Database integration - Database integration ae 
- Investigate network infrastruc- - Manage web accounts (login, = View patient data from 

; other institutions 
ture expansion password, etc.) 

- User interface design (UID) - Patient views own data from The 


g j Health Center 
- Site security 


- Manage web accounts (login, ~ Change personal data 


and preferences 
password, etc.) pi 


i , r - Manage appointments 
- Patient views own data from The ee EPP 


Health Center 


- RISK Current web site capacity 


- RISK Patients with “edit” access 


could damage data 


FIGURE 2.14 Example roadmap from clinic user website case 


Agile Release Planning 

The release map (or product roadmap) was created during Initiation, along with the feature backlog. In release planning 
these will be planned further for the release of the first increment of the product. Once that first increment is released the 
team begins work on the second release, and so on, for the number of releases decided on by the team during initiation. The 
release plan is developed iteratively throughout the project because in adaptive environments planning occurs throughout 
the project. Other activities the team carries out are as follows: 

* Features are “sliced,” or decomposed into smaller units, or stories. The stories are estimated in finer detail using 
estimating tools like Planning Poker*, where each story is estimated using more finely detailed relative sizing. 
Additional requirements about the stories are gathered as they can become known, and a “definition of done” (i.e., 
what does “done” look like?) is created for each story. 

* The team establishes its initial “velocity,” which is a measure of how much work can be completed in an iteration (a 
defined period of time for building the product increment, like two weeks, or three weeks, for example). The team also 
selects, with the help of the product owner who is responsible for prioritizing the backlog, the stories that will be 
completed in the first iteration. 

+ The team continues to gather the detailed requirements for the first (or next) iteration. The product owner, meanwhile, 
is continuously prioritizing the backlog. The project manager is fostering a common understanding and removing 


impediments for the team. 
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Agile Iterations and Product Release 

Monitoring and controlling occur throughout an agile project as the product is being built, although most agile practitioners 
do not use the term “monitoring and controlling.” The team moves through a defined series of iterations (two-to-four 
usually) per release, until a product increment is ready to be delivered to the customer. This is what these processes 
look like: 


* There is a last, quick effort to finish the iteration planning before the iteration begins. Once the iteration begins the 
team will simply build the stories that have been selected for that iteration while the project manager is facilitating 
their work and removing impediments to progress. 


+ The team has already begun daily standup meetings, which are very short meetings (usually 15 minutes) where they 
discuss what has been completed since they last met, what will be completed next, and whether there are any 
impediments to progress. Any elaboration or follow up from the meeting happens after the meeting so everyone can 
get back to work quickly. 

+ The team’s work consists of building, testing, and finishing stories so they can be presented to the customer for 
approval in an iteration review, where the product is demonstrated and the customer has an opportunity to 
provide feedback. 


e The product owner meanwhile is answering questions the team has about missing story details, prioritizing the 
backlog, and preparing more stories for the next iteration by continually gathering their detailed requirements. 

+ After the iteration review, the team responds to customer feedback requiring changes. The team also holds an iteration 
retrospective where they discuss what they did well, what went wrong, and what they would do differently. The daily 
standups, the iteration reviews, and retrospectives are all part of living a philosophy of continuous improvement. 


e Iterations continue until a “minimally marketable” increment of the product is ready for release to the customer. 
Minimally marketable increments are those that meet the minimum requirements for something that the customer 
can use while the team builds the next product release. 


Agile Closing 

There is no appreciable difference between closing processes in adaptive and predictive environments. You can review this 
information in the Closing section on Rita’s Agile Process Chart”. Essentially the team obtains final approval of the last 
product increment to be released during the project, turns it over to the customer, and holds their final retrospective. The 
project manager also makes sure all procurements have been closed and that all project artifacts are current and are archived 


as part of the organizations process assets. 


py i 
Rita's Agile Process Chart™ Game 
Rita’s Agile Process Chart™ game will help you gain understanding on how an agile project flows. We suggest you only play 
the game once before you have read through this book. Then return to it as many times as you’d like to increase your 
understanding of agile projects. 
. An online version of Rita’s Agile Process Chart™ Game is available at rmcels.com/ 
agile-process-chart-game-vl 1. 
+ A printable version of the game is available for download. This version is available on our RMC 
Resources page: rmcls.com/rmc-resources. You can then cut apart the component “cards” and 


play the game. 


RMC RESOURCES 


R Hybrid approaches embody the principle of tailoring. As you read this book, use your 
experience to practice awareness of tailoring. Think about tailoring the processes and 
Ili ls discussed in this book with projects you are familiar with and examples we give you. Could you be 
creative with project management methods to better manage a situation on a project? Think about advantages 
the different approaches offer. As you become comfortable with these approaches, you will be able to identify them on 


the exam depending on the given scenario and therefore select the best answer. 
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Hybrid Environments 
A hybrid project management environment uses a combination of plan-driven and agile development 
approaches. These approaches may take one of many forms. Below are a few examples: 
+ We can use predictive methods to manage project requirements that are well defined, and adaptive fale 
methods to manage requirements that are less clear. 
Example Build a small building with plan-driven methods. Build out office spaces iteratively. 
+ Use a plan-driven approach but add agile elements. 

Example The project manager for a mainly plan-driven project uses electronic task boards (“information 
radiators” in agile) for a remote team and institutes daily standup meetings during designated periods along the 
critical path. 

+ Use an adaptive approach to develop the product and then use a predictive approach to implement the product once 
it has been approved for release. 


Example Develop a large, complex software installation incrementally and iteratively. Once it is ready to be 
released, complete the rollout and training using plan-driven methods. 


Figure 2.15 illustrates the spectrum of development approaches, using the small office building construction example 


from chapter 1. The dotted line indicates that with a hybrid approach, any combination of methods along the spectrum 
maybe used. 


Plan-driven approach to construct building 


Combination plan-driven and agile for interiors as space is leased 


FIGURE 2.15 Development Approach Spectrum 


PMBOK® Guide, Seventh Edition Overview 


As we mentioned earlier in this chapter, PMI states that the exam is based on the ECO but also gives ten other references, 
including the PMBOK* Guide, Seventh Edition. Since we have found that you could see questions on the exam based on 
information in the PMBOK* Guide, we want to provide an overview. We will also present concepts from it throughout the 
book, where appropriate. 


Updates in the PMBOK® Guide’s Seventh Edition 
The seventh edition of the PMBOK* Guide is not prescriptive since it does not endorse a single framework or approach to 
good project management. Connected to this idea of not endorsing a single project management model, the PMBOK* 
Guide describes the continuum of approaches along which projects maybe managed. This continuum of practices ranges 
from managing projects using only plan-driven methods, to doing so using only agile methods. Between these two extremes 
are hybrid models that combine methods from both plan-driven and agile project management. 

Anywhere along this continuum, remember, is the basic tenet of tailoring. You must tailor your project management 
approach and methods to the needs of the project you are managing and its potential benefits to your organization and its 
stakeholders. These benefits tie back to the reason a given project was selected by the organization. 


Other fundamentals in the PMBOK* Guide to think about focus on project management as: 


* A system of value delivery You still need to understand the definitions of projects, programs, portfolios, and 
operations from the perspective of their unique attributes and connections to one another. PMI now also emphasizes 
thinking of these collective efforts from the perspective of a system of delivering value to the business and to achieving 
its strategic objectives—and those of its stakeholders. These two perspectives are completely compatible with each 
other, with the principles in the ECO, and with everything we teach in this book. 
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+ A principles-based system Complementary to PMI’s Code of Ethics and Professional Responsibility, PMI 
introduces the PMBOK' Guide as a principles-based system of managing projects to deliver value. These principles are 
listed later in this book, in the “PMBOK* Guide and the PM Standard” chapter. 


+ Having a performance domain focus The PMBOK* Guide is based on performance domains, each of which 
describe a collection of skills and abilities that a project manager should have and use on a project, in whatever ways 
necessary depending on the project s neéds and attributes. 

The PMBOK* Guide's performance domains are not the same as those described in the ECO, but they are 
compatible with them. Do not worry about having to memorize all these performance domains. It will not be hard for 
you to relate to the PMBOK* Guide's performance domains as you gain an understanding of plan-driven, agile, and 
hybrid project management approaches (along with the concepts expressed in the ECO), as taught in this book. The 
domains are: 


y Stakeholders -/ Planning -/ Measurement 
m/ Team m/ Project Work m/ Uncertainty 
-/ Development Approach +/ Delivery 

and Life Cycle 


+ An outcomes-based system Projects inevitably deliver outputs—those deliverables that result from the project- 
related activities the project manager and team complete. There is a difference between outputs (deliverables directly 
resulting from the work on a project), and outcomes—what needs to be accomplished with these deliverables. The 
PMBOK* Guide places an increased emphasis on the outcomes that should result from these deliverables. 

Example It is one thing for a project to deliver improved sales and engineering processes (the outputs, or 
deliverables), but do these new or improved processes achieve the desired outcome of measurably improving sales 
results? The output of the project is the new or improved processes, and the desired outcome is the measurable 
improvement in sales and product delivery. 

* Models, methods, and artifacts A model is a way of understanding a concept or a set of tools, a method is the set 
of tools itself, and artifacts are all of the documentation and other useful organizational assets project managers use on 


a project, keep updated, and leave behind from a properly managed project. 


Putting It All Together 


We would like you to have more practice with the two main project management process models before you read the rest 
of this book. 

Read through the concepts in the first column (the Agile column), and study how they are illustrated in the Agile 
Process Overview in figure 2.16. The Agile Process Overview will help you better understand the agile model. Next, read 
through the concepts in the plan-driven column and go back to Rita’s Process Chart™ earlier in this chapter and read 
through it again. 

Make sure you understand both process models and, at a high level, how they are similar to and different from each 


other. 


It is useful to draw parallels between plan-driven and agile project management so that you may understand 
both, along with their similarities and differences. As we show these parallels also keep in mind that they are 
models, and all models have limits. So do not look for exact parallels from these comparisons. Come to a 


general understanding that each approach arrives at the same goals by taking different paths. 
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Agile (Agile Process Overview, figure 2.16): Initiating Plan-driven (Rita’s Process Chart™: Initiating) 
- Chartering and identify stakeholders: Personas. - Project charter and identify stakeholders: 
- Create Backlog: High-level requirements; features Stakeholder register. 
and functions. - High-level known requirements: In project charter. 
- High-level estimation: Bucket size (like t-shirt size: S, M, - High level estimation: In project charter. 
L). 


- Create roadmap: Time-phased story map. 


Agile (Agile Process Overview, figure 2.16): Release 


Planning and Iteration Planning Plan-driven (Rita’s Process Chart™: Planning) 

- Story slicing Decomposed from _ feature-level (high-level) - Gather requirements, define scope, decompose to create 
to smaller chunks of functionality (stories). WBS (work packages) and WBS dictionary. 

- Story estimation using Planning Poker*: An all-team - Create activity list, estimate activity durations, costs, 
participatory estimating method. resource requirements. 

- Cost and schedule (not shown on figure 2.16): Cost is - Build the rest of the project management plan (detailed 
stable and estimated early; scope is emerging and quality, procurement, communications, stakeholder, 
more negotiable. and risk plans). 

- Build a release plan: Risk-adjusted backlog contains - Team charter, roles and responsibilities. 


sliced stories; prioritized sufficiently to plan the (first + Go back - iterations, create change and configuration 


and) next iteration. Quality, procurement, communica- fee 
) Quality, p plans. Finalize procurement and other management 


tions planned in. plans. Get final project management plan approval, hold 


- Team charter, roles, & responsibilities: SMEs as general- kickoff meeting. 


izing specialists (can help where needed); project 


Project manager and team consult plan for next steps; 


manager/servant leader; product owner represents adjustments are made as needed. 


the customer. 


Project manager as servant leader. 


- Iteration 0 and spikes: Detailed requirements are Technical build ith I 
gathered in Iteration 0. Spikes are experimental iterations CA OA BUGS ENERE NoE 


to explore a new risk, technology, or approach. - Project manager controls to the plan. 


- Iteration planning: Short, whole-team meeting (the team - Meetings for various reasons including project 


manages their own work). reporting. 


Project manager as servant leader. Servant leader (project manager) helps remove 
impediments, engage stakeholders, manage procure- 


ments, etc. 


Building with excellence: Technical team. 


- Answer questions; prepare stories for next iteration: 
Product Owner/value management. 


Meetings to execute and control, including integrated 
change control and project reporting. 


Daily standup meetings: Short—What is done; what are 


you working on; are there impediments? - Executing and control continues; replanning happens 


for approved changes; iterative planning happens for 
- Servant leader (project manager): Helps remove progressive elaboration as needed. 
impediments after the meeting. 


Product scope is built, verified, and validated (accepted) 
- Iteration review: Demo product increment to customer, until scope as planned is completed and the project can 
get feedback, and go back to make changes as needed. close (or the project is terminated early). 


Planning executing, and control: happens iteratively 
until defined product scope is built or the customer 
decides that the built scope is enough and the project can 
close (or the project is terminated early). 
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After a release, we go to release planning for another 
release or, if it is the final release, we close out the project. 


Feasibility Initiation 


Release Planning | 


© Whole team or available team members 
O Value management (product owner) team 
e Technical development team 

O Testers 


Inage credit: Ahmed Sidky, Santeon Group, www.santeoncom 


FIGURE 2.16 Agile Process Overview 


52 


3 Project Management 
Foundations 


This is a very important chapter. Yes, we could say that about every chapter in this book, as they all will 
add to your understanding of project management. But this chapter is especially important because it 
provides the foundation for understanding the other chapters in this book. Use the Quicktest to look 
for gaps in your knowledge and work on filling those gaps as you read the rest of the chapter. 


Project Management's Organizational Context 


Successful projects provide business value and deliver benefits defined in a business case and a benefits 
management plan. Projects are designed to bring value to an organization and its stakeholders by add- 
ing or improving products or services, and in some cases to satisfy regulatory or other legal require- 
ments. They are selected, initiated, and exist within an organizational context that influences their de- 
sired outcomes and what is needed (inputs) to work to achieve these outcomes. Organizational context 
includes an organizations dperations and projects, its governance, and its organizational structure. 


Organizational context also includes what the PMBOK* Guide calls influences: enterprise 
environmental factors (EEFs) and organizational process assets (OPAs). EEFs are outside the control 
of the project team but impact its work, like an organizations culture, technology, and external 
governmental standards, rules, and regulations. OPAs are an organizations processes, procedures, and 
policies, along with organizational knowledge repositories — things within the organization that can 
facilitate the work of project management and product development. A project manager and team use 
these and update them for the organization. We will discuss other aspects of project management’s 
organizational context when we discuss the Business Environment domain of the PMP Examination 
Content Outline fF .COY 


Operations and Projects 

Most work done in organizations can be described as either operational or project work. Operational 
work is ongoing work to support the business and systems of the organization, whereas project work 
ends when the project is closed. People often see their work as a project when it is not. 

Example A person who processes payroll every month may consider this a monthly project. 
Technically, this repeatable process is part of operations. Now, what’s wrong with this thinking or with 
using project management techniques to get the job done? Nothing. In fact, project management 
methods can be used in many areas of work and life. But for the exam, you should understand the 
distinction. 

A project has a distinct beginning and end, and is an effort to produce something that has not 
been done before. When a project is finished, the deliverables are transitioned to ongoing business 
operations so the value and benefits of the project work can be integrated into the organization, 
permanently or until another change to that operation is needed. A successful transition may require 
employee training or adjustments to operational processes. 


Example An insurance company’s internal project to develop a new caseload tracking system is 
completed. As part of the same project or as a different project, the new system has to be launched. 
Employees will need to be trained on how to use the system and to adjust their ways of working to 
incorporate the new system into their daily work so the benefits can be realized. And this relationship 
goes both ways. While a project may develop a product or service to be used in operational work, the 
need for change to operational work may prompt the initiation of a project. Here are ways that could 
happen in the caseload tracking system example: 


QUICKTEST 


Definition of a project 

* Program management 

* Portfolio management 

* Organizational project 
management (OPM) 

+ Governance 


Organizational structure 

- Functional 

- Project-oriented 

- Matrix 
Project coordinator 
Project expediter 

+ Project management 
office (PMO) 

- Supportive 

- Controlling 

- Directive 


e Value delivery office 
(VDO) 

+ Return on investment 

(ROI) 

Present value (PV) 

* Net present value (NPV) 

+ Internal rate of return 
(IRR) 

* Payback period 

* Cost-benefit analysis 

+ Economic value added 
(EVA) 

e Opportunity cost 

* Sunk costs 

e Law of diminishing 
returns 

Working capital 

Depreciation 
Project roles 

- Project manager 

- Agile Team Leader 
e Agile coach 
+ Team lead 
+ Scrum Master 

- Product owner 

- Product manager 


- Project sponsor/Initiator 

- Project team 

- Stakeholder 

- Functional or resource 
manager 

- Program manager 

- Portfolio manager 


53 


Project Management Foundations THREE 


* The need for a new caseload tracking system may have arisen from problems occurring in the organizations 
business operations. 

+ Imagine the caseload tracking system has moved into operations and users have started working with it, but some 
bugs have been identified. Fixing these bugs would likely be addressed as the operational work of maintaining business 
systems rather than as a new project. 

+ The organization decides to add new features to the caseload tracking system after it is in operation. This would 
prompt a new project. 


Projects, Programs, and Portfolios 
The PMP exam mostly focuses on project management, but understanding a bit about how projects fit into programs and 
portfolios will help you approach the exam with a holistic understanding of the context in which projects are managed. 


Project and Program Management 
On the exam, a project is assumed to have the following characteristics: 


e Itis a temporary endeavor—with a beginning and an end. 

+ It creates a unique product, service, or result. 

+ It is undertaken to drive a change in a product or process from a current state to a future state, to achieve a 
specific objective. 

+ It is undertaken to create business value for the organization and its stakeholders. PMI’s Process Groups: A Practice 
Guide defines business value as “the net quantifiable benefit derived from a business endeavor.” The benefit may be 
tangible, intangible, or both. 


Does the exam ask, “What is a project?” No. But it will describe scenarios and your answer will be different if the 
scenario is not describing a project. If your manager walked into your office today and said, “The system is broken. Can you 
figure out what is wrong with it and fix it?” Would this be a project? 

It depends. On the exam, the right answer will depend upon the evidence given in the question. In this book, we will 
give you some tricks about answering questions. 


Projects are selected among many possible business endeavors for a variety of reasons including: 

+ Stakeholder (customer) needs and requests for new or improved products or services, often initiated by market forces 
or by the stakeholders themselves 

+ Improvements to the performing organizations business or technology strategies and/or their products or services 

+ Satisfy regulatory, legal, or social requirements 


A program is a group of related, sub-projects and other program-related activities, organized and managed into a 
coordinated set of efforts. In addition to the work required to complete each individual project, the program also includes 
a program managers coordination and management activities. The project manager will collaborate with a program 
manager if the project is part of a program. If the assigned work involves more than one project, the project manager can 
manage the projects as a program if they determine the program approach adds value. Figures 3.1 and 3.2 illustrate program 
and portfolio management. Portfolio management and PMI’s Organizational Project Management (OPM) framework are 


discussed in the sections that follow. 
FIGURE 3.1 Program management [ - 7 — 


FIGURE 3.2 Portfolio management 
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Portfolio Management 


A portfolio includes programs, projects, and related operational work, all prioritized and implemented to achieve a specific 
business objective (see figure 3.3). Programs and projects that make up a portfolio may not be related, other than by their 
relationship to this common business objective. A portfolio may also include smaller, subsidiary portfolios. Combining 
programs, projects, and operations into one or more portfolios helps to manage the dependencies between them and the 
individual projects. It also optimizes the use of resources, enhances the value they produce for the organization and its 
stakeholders, and reduces risk. The work of an organization comprises one or multiple portfolios. A project is included in 
a portfolio based on potential return on investment, strategic benefits, alignment with corporate strategy, and other factors 
critical to organizational success. 


Organizati Proje t (OPM 

Organizational project management (OPM) serves as a guide 
or driver for project, program, and portfolio management as 
well as other organizational practices. It is a framework for 
keeping the organization focused on overall strategy. OPM 
provides direction for how portfolios, programs, projects, and 


ganization's 


operational work should be prioritized, managed, executed, Portfolio Management 
and measured to best achieve business objectives and value Selects and prioritizes programs 
= A p s 
for the organization and its stakeholders. g e Aniiprojacts'ttiat will bast actions: 
E 3 the organization's strategic goals 
A 
Think About It. Take a couple of minutes to think g £ 
+ . + + + 5 g Pr Mi t 
about the information depicted in figure 3.3, which g S ei EE 
D r = i &  & Coordinates the management of related 
a shows how OPM drives an organization to achieve S 3 projects to achieve specific benefits that 
i ee 5 f i 
business objectives. > = support the organization's strategic goals 
: i , 5 £ 
A key point to understand is that all efforts in the S = Project Management 
organization—whether they are part of project, program, © Manages efforts to develop specific scope, 
; : 2 Which supports the portfolio or program 
portfolio management, or operational work—should be v = management objectives and, ultimately, 
guided by the organization and support its business objectives. the organization's strategic goals 


Changes to organizational strategy will necessitate changes to 
the affected work in each of these areas—both ongoing efforts 
and future initiatives. a i 
Example If a project no longer aligns with organizational FIGURE 3:3 Ongantzationalipriject management 


strategy, the project may be changed midcourse to bring it into alignment, or it may be terminated. 


Organizational and Project Governance 

Every organization is different, and organizational governance is designed to support the specific culture and attributes of 
the organization. Organizational governance affects and is affected by project governance, the organizations culture and 
structure, and the business environment. 


Organizational Governance 


Organizational governance refers to the the way an organization sets the policies and procedures for how work will be 
performed to meet business objectives and to support decision-making. Generally, a board of directors is responsible to 
ensure that work throughout the organization conforms to external (government or regulatory) and internal standards and 
requirements. Internal requirements include policies and procedures regarding portfolio, program, project, and operations 
work to ensure that these are all within the strategic plan of the organization and that they contribute to the delivery of 
business objectives while meeting ethical, social, and environmental sustainability obligations. 


Project Governance 


In the Examination Content Outline (ECO), task 14 of the Process domain is to establish project governance structure. It 
requires project managers to ensure their project management practices align with organizational governance. Do you 
establish a project governance structure on your projects? Regardless of what type of project you are managing, you are 
still responsible to understand your organizations governance and align your project's governance to it. 
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Project governance can be established and administered by a project management office (PMO—see the PMO 
section later in this chapter). It may involve defining a project manages authority and the creation or enforcement of 
organizational processes and policies regarding areas such as risk, resources, communications, and change management. 

Governance may also involve planning and managing project compliance in regulations, security, and safety. The 
awareness of these requirements helps shape the best approach for a project. 

Example Potential regulatory restrictions on a new energy project might inform the project manager as to when a 
project must be completed. It may also help determine the approach and methodology for developing the product of the 


project. 

How does governance differ between predictive and adaptive projects? Predictive governance typically A 
involves formal documentation and upfront analysis and agreement. Agile governance, in contrast, is 
generally less structured but still aligns with the necessary policies and procedures of the organization. band 

ocus 


Organizational Structure 

Along with organizational and project governance, a primary form of influence on projects is how the company is 
structured. The organizational structure establishes who the project manager goes to for help with resources, how 
communications must be handled, and other aspects of project management. 

An answer to a question on the exam can change depending on the structure of the organization being discussed. 

Exam questions are sometimes phrased in terms of the project manager $ level of authority and how the form of organization 
impacts their management of projects. Exam questions may deal with who has the power in a particular type of organization 
or situation (the project manager or the functional manager), or they may require you to understand the advantages and 
disadvantages to the project manager in each type of organization. 
As you read through the following sections defining the different organizational structures, take time to think about 
how each form would impact your work as a project manager and how you would solve problems in different situations 
within each structure. In the real world individual organizational structures can vary within these general models, but on 
the exam you will be able to see clear distinctions between them in the scenarios given in the questions. 


Functional Organizations 


Functional organizations are common and are grouped by areas of specialization, such as accounting, marketing, or 
manufacturing. Projects generally occur within a single department, so when you see “functional” on the exam, think “silo.” 
If information or project work is needed from another department, employees transmit the request to the head of the 
department (one silo) who communicates the request to the other department head (another silo). Team members 


complete project work in addition to normal departmental work. 


Project-oriented Organizations 

In a project-oriented or projectized organization, the entire company is organized by projects. The project manager has 
complete project control and project resources are assigned and report to them. When you see “project-oriented” on the 
exam, think “no home.” Team members complete only project work, so when the project is over, they do not have a 
department to go back to. They need to be assigned to another project or get a job with a different employer. Communication 


primarily occurs within the project. 


Matrix rganizations 


This organizational model seeks to maximize the strengths of both the functional and project-oriented models. When you 
see “matrix” on the exam, think “two managers.” Team members report to two managers: the project manager and the 
functional manager (e.g., the engineering manager). Communication goes from team members to both managers. Team 
members do project work in addition to operations work. Following are the different subcategories of matrix organizations: 

+ A balanced matrix shares the power between the functional manager and the project manager. 

* Ina strong matrix power rests with the project manager. 


+ Ina weak matrix power rests with the functional manager, and the power of the project manager is comparable to that 
of a coordinator or expediter: 


>/ A project coordinator has some authority and can make some decisions but reports to a higher-level manager 


>/ A project expediter organizes communications and assists administratively but cannot make or 
enforce decisions. 
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3.1 Exercise 


Project Management Foundations 


Exam questions typically do not identify the form of organization being discussed; in which case you should 
assume matrix. This is most common and will help you answer questions correctly. 


A “tight matrix” has nothing to do with a matrix organization. It simply refers to colocation—the practice of 
locating workspaces for the project team in the same room. Because it sounds similar to other forms, it has 
sometimes been used as a fourth choice for multiple choice questions on the exam. 


Test yourself! In your Exercise Notebook, list the advantages and disadvantages of each organizational structure: 
functional, project-oriented, and matrix. Understanding the differences between these structures will help you 
evaluate scenarios presented on the exam, and you'll be able to choose the right answer within that context. 


Answer 


Functional Organizations 


Advantages 


+ Easier management of specialists 

* Team members report to only one supervisor 

+ Similar resources are centralized, as the company 
is grouped by specialties 

e Clearly defined career paths in areas of work 
specialization 


Project-Oriented Organizations 


Advantages 
+ Efficient project organization 
+ Team loyalty to the project 
+ More efficient communications than functional 


+ Project manager has more power to make 
decisions 


Matrix Organizations 


Advantages 

+ Highly visible project objectives 

+ Improved project manager control over resources 
(as compared to functional) 

+ More support from functional areas 

+ Maximum utilization of scarce resources 

+ Better coordination 

+ Better horizontal and vertical dissemination of 
information 

+ Team members maintain a “home” 


Disadvantages 


. 


People place more emphasis on their functional 
specialty to the detriment of the project 
Limited career path in project management 
The project manager has little or no authority 


Disadvantages 


No “home” for team members when project is 
completed 

Lack of specialization in disciplines 
Duplication of facilities and job functions 
May result in less efficient use of resources 


Disadvantages 


Extra administration is required 

Project team members have more than one 
manager 

More complex to monitor and control 

Resource allocation is more complex 

Extensive policies and procedures are needed 
Functional managers may have different priorities 
than project managers 

Higher potential for conflict 
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The Project Management Office (PMO) _ 


The PMO is a department within an organization that can take a number of different forms based on an individual 
organizations’ structure. A PMO supports projects, helps the organization mature its project management capabilities, and 
helps ensure compliance with project governance. The PMO oversees and standardizes project management practices for 
the organization. 


Depending on the structure of the organization and its PMO, the PMO may: 


© Bea stakeholder © Help provide project resources 
® Prioritize projects ® Manage the interdependencies among projects, 
® Monitor compliance with organizational governance programs, and portfolios 
è Facilitate the achievement of project outcomes with ® Provide centralized communication about projects 
the project manager © Provide project artifact templates (e.g., work 
© Analyze project information to assess whether it is breakdown structures, user stories, communications 
achieving its objectives and aid in management plans) 
continuous improvement © Provide training and support for the acquisition of 
© Recommend the termination of projects project management skills 
when appropriate è Help gather lessons learned into a repository and 
è Have representation on the change control board; make them available to other projects 
help with change management © Assist in selection of project development approach 
è Provide guidance for the project manager and and life cycle 
sponsor in decision making © Assist in tailoring strategies and tactics 


A PMO can take one of several forms. A PMO may be described as supportive, controlling, or directive based on the 
level of control it maintains over the management of projects, or it may take on a variety of these roles based on the size and 
complexity of the organization and its structure. Following are scenarios that describe ways in which a PMO may operate: 

+ A supportive PMO provides the policies, methodologies, templates, and lessons learned for projects within the 

organization. It typically exercises a low level of control over projects. 


+ A controlling PMO provides support and guidance on how to manage projects, trains others in project management 
software and other tools, and ensures compliance with organizational policies. It typically has a moderate level of 
control over projects. 

+ A directive PMO provides project managers for different projects and is responsible for the results of those projects. 
All projects, or projects of a certain size, type, or priority are managed by this office. A directive PMO has a high level 
of control over projects. 

* Characteristics of above types may be combined depending on the organizations needs. 

+ A functional organization may have departments that control how projects are run within them, but may get support 
from a central PMO for various needs like those services described for a supportive PMO. The PMO may also provide 
help with other things—for example risk assessment based on internal and external environmental conditions, or 
project performance tracking where the project manager or team may need help with it 


Value Delivery Office (VDO) Some organizations with less hierarchical structures and more adaptive A 
project management environments have a value delivery office or Agile Center of Excellence (ACoE) to \ 


better enable project management in this type of environment. P4 bv 


When answering exam questions, assume there is a PMO, unless the question indicates otherwise. Read 
questions carefully to determine if the PMO is supportive, controlling, or directive. 
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3.2 Exercise 


Read each description of a PMO. Determine whether it is likely to be supporting, controlling, directive, or a 
combination of two or three. Write the answers in your Exercise Notebook. 
Description 


1. Manages all projects throughout the organization 


2. Provides support and guidance; requires all projects within the organization to use designated project 
management software and templates, but doesn’t otherwise exert control over the project 


3. Coordinates all projects within the organization 


4. Recommends common terminology, templates, reporting, and procedures to be used on projects 
throughout the organization to promote consistency and streamline efforts 


5. Appoints project manager 
6. Prioritizes projects 


7. Has the highest level of control over projects 


Answer 
1. Directive 
Controlling 


Controlling or Directive 


Poo fa 


Supportive 
5. Directive 
6. Controlling or Directive 


7. Directive 


Project Selection 


A project manager should know a project's history in order to manage it effectively and achieve its intended deliverables and 
outcomes. Departments and individuals within your company present management with requests for many different initia- 
tives (potential projects), all of which would require an investment of corporate resources. When answering questions on 
the exam, assume that the organization has a formal process to review and analyze potential projects and select the projects 
that best align with the business objectives of the organization and its stakeholders. There might even be a project selection 
committee in place to evaluate project proposals. 


How Projects Are Selected 


A project manager is not typically involved in project selection. So you might ask, “Why is this an important topic to 
understand?” Good question! Think of it as one element of understanding the business environment. The reasons a project 
is selected and the value it is expected to deliver indicate its significance to the organization. As a few common examples, 
as a project manager you need to know if your project: 


+ Was selected because it will establish a new area of business 
+ Is being implemented to meet regulatory or compliance requirements 


+ Was chosen because it was the least expensive or most feasible solution to a problem 
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The reasons a project was selected can impact which constraints are most flexible and will influence how the project 
manager plans and manages the project. A project manager must keep the reasons the project was selected in mind 
throughout the project to ensure the objectives are achieved. 

For the exam, you should be familiar with the project selection methods described next. Just knowing that such 
activities occur prior to initiating a project will help you. Project selection activities fall outside the project boundaries (or 
period from project authorization through closure). 


Economic Measures for Project Selection 
The following sections discuss several economic measures that can be used for analyzing potential projects for selection. 
Some of these measures are also used in processes such as quality, cost, and risk management, and in integrated change 
control. The measures take a comparative approach and can be used to develop project metrics, determine when changes 
to the plan are needed, and evaluate progress, changes, and overall project success. 

An organization would likely consider more than one of these measures (along with other factors) when selecting a 
project, rather than any one measure on its own. 


Return on Investment (ROI) 
Return on investment determines the potential profitability of an investment by calculating the benefits received in relation 
to the cost. 


Present Value (PV. 


You may encounter a question on the exam that requires you to calculate present value. Present value means the value 
today of future cash flows, and it can be calculated using the formula shown in figure 3.4. 


FV FV = future value 
PV ane r = interest rate 
(1+r) n= number of time periods 


FIGURE 3.4 Present value formula 


The acronym PV is also used for planned value (described in the “Cost” chapter). You can avoid confusing these 
terms by considering the context in which they are used: 


+ Ifthe question is discussing how the project was evaluated for selection or funding, PV represents present value. 


+ If the question involves project work that has started and schedule or cost performance is being evaluated, then PV 
represents planned value within earned value management (EVM). 


oe ‘Think About It. Think about the following question: 
oO Question: 


pan Is the present value of $300,000 to be received three years from now, with an expected interest rate of 10 percent, 
p! y pi p 
more or less than $300,000? 


Answer: 
Less. You can put an amount of money less than $300,000 in the bank and in three years have $300,000. 
To perform the calculation: $300,000/(1 + 0.1 )! = $300,000/1.331 = $225,394. 


Net Present Value (NPV) 4 

NPV is the present value of the total benefits (income or revenue) minus the costs over many time periods. You will not 
have to calculate NPV. Know that generally, if the NPV is positive, the investment is a good choice — unless an even better 
investment opportunity exists. The project with the greatest NPV is typically selected. 
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E Think About It. Do you already have a good understanding of this topic? Think about the following question. 


0 Question: 

cay An organization has two projects from which to choose. Project A will take three years to complete and has an 
NPV of $45,000. Project B will take six years to complete and has an NPV of $85,000. Which one is a 
better investment? 


Answer: 


Project B. The number of years is not relevant, as that would have been considered in the calculation of the NPV 
(remember, over many time periods). 


Internal Rate of Return (IRR) 

To understand internal rate of return, think of a bank account. You put money in a bank account and expect to get a 
return—for example, 1 percent. You can think of a project in the same way. If a company has more than one project in 
which it could invest, the company may look at the returns of the different projects and then select the project with the 
highest return. 


IRR does get confusing when you give it this formal definition: The rate (interest rate) at which the project inflows 
(revenues) and project outflows (costs) are equal. Calculating IRR is complex and requires the aid of a computer. 


You will not have to perform any IRR calculations on the exam. Simply know that the higher the IRR number, the 
better. 


ae Think About It. An example is always a good way to remember something so think about the next example. 
Question: 


a. An organization has two projects from which to choose: Project A with an IRR of 21 percent and Project B with 
an IRR of 15 percent. Which one is a better option? 


Answer: 


Project A 


Payback Period 
The term payback period refers to the length of time it takes for the organization to recover its investment in a project 


before it starts accumulating profit. 


oe Think About It. Here is an example to think about for the concept of payback period. 


£' Question: 
aay There are two projects from which to choose: Project A with a payback period of six months and Project B with 
a payback period of eighteen months. Which one should the organization select? 
Answer: 
Project A 


Based on the information given in this example, the project with the shorter payback period is the best choice, but 
that payback period is likely to be one of several financial factors, along with other considerations used in selecting a 
project. Remember to look at all the factors given in an exam question scenario. The best choice might be a project that has 
a longer payback period but has other advantages. 


Cost-benefit Analysis 


A cost-benefit analysis compares the expected costs of a project to the potential benefits it could bring the organization or 
its stakeholders. This analysis results in a calculated benefit-cost ratio, which can be expressed as a decimal or a ratio. 
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The resulting “benefit-cost” ratio flips the terms in the more familiar “cost-benefit analysis.” Don’t be distracted 
by that on the exam. 


a A benefit-cost ratio of: 
e Greater than 1 means the benefits are greater than the costs. 
+ Less than 1 means the costs are greater than the benefits. 


+ Exactly 1 means the costs and benefits are equal. 


Question: 


oe Think About It. 


What does a benefit-cost ratio of 1.7 mean? 
A. The costs are greater than the benefits. 
B. Revenue is 1.7 times the costs. 
C. Profitis 1.7 times the costs. 
D. Costs are 1.7 times the profit. 
Answer: 


B. The benefits, or revenue, the project brings to the organization are 1.7 times the cost of the initiative. Remember, 
the benefit-cost ratio calculation is looking at revenue, not the smaller figure of profits. 


Other things to know about this concept are: 


. 


The organization may use the benefit-cost ratio to help choose from many potential projects. 

A project manager may perform cost-benefit analysis to determine the best solution approach to a selected project. 
The project manager may perform the analysis at a high level during initiating and at a more detailed level during 
planning. This information helps determine things such as what level of quality efforts are appropriate for the project, 
what equipment or technology should be purchased, and whether it would be best to outsource certain pieces of work. 


3.3 Exercise 

Remember, you do not have to use accounting formulas to pass the exam (aside, possibly, from a present value 
question). But you do need to have a general understanding of what the terms mean. Test yourself! For each row of 
the following chart, write in your Exercise Notebook which project (A or B) you would pick based on the 
information provided. 


Project A Project B 
1. Net Present Value $95,000 $75,000 
2. IRR 13 percent 17 percent 
3. Payback period 16 months 21 months 
4. Benefit-cost ratio 2:79 13 


Answer: 
L.A 
2.B 
3.A 
4A 
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The following are some additional accounting terms related to project selection. Each one you are familiar with could 
mean a point or more on the exam. 


Economic Value Added (EVA) i 
For project selection, EVA asks whether the project returns more value than it costs. 


Note: This is a different concept than earned value analysis (also known as earned value management or EVM), 
which can also have the acronym EVA. Earned value analysis (EVA) (in the “Cost” chapter) is more frequently mentioned 
on the exam, whereas economic value added appears rarely. 


Opportunity Cost 
The term opportunity cost refers to the opportunity given up by selecting one project over another. This does not require 
any calculation. 


oe Think About It. Think about the following example. 
Question: 


roa An organization has two projects to choose from: Project A with an NPV of $45,000 and Project B with an NPV 
of $85,000. What is the opportunity cost of selecting Project B? 


Answer: 


$45,000. The opportunity cost is the value of the project not selected. 


Sunk Costs 
Sunk costs are expended costs — what you already spent, in other words. Sunk costs should not be considered when 
deciding whether to continue with a troubled project. 


a Think About It. Those who are unfamiliar with accounting standards have trouble with the following question. 
@ Question: 
rae An organization has a project with an initial budget of $1,000,000. It is half complete and has spent $2,000,000. 
Should the organization consider that it is already $1,000,000 over budget in determining whether to continue 
with the project’? 
Answer 


No. The money spent is gone. 


Law of Diminishing Returns 


This law states that after a certain point, adding more input (for example, programmers) will not produce a proportional 
increase in productivity (such as modules of code per hour). A single programmer may produce at a rate of 1 module per 
hour. With a second programmer, the two may produce at a rate of 1.75 modules per hour (0.75 increase). With a third 


programmer, the group may produce at a rate of 2.25 modules per hour (0.5 increase). This disparity may be due to many 
factors. For example, additional coordination is required as more programmers are added to a project. 


Working Capital 


This term refers to an organizations current assets minus its current liabilities. In other words, it is the amount of money 
the company has available to invest, including investing in projects. 


Depreciation 


Large assets, such as equipment, lose value over time. This is called depreciation. Several methods are used to account for 
depreciation. The exam may ask you what they are. You will not have to perform any calculations. (See, we said we could 
make this easy for you!) Rather, you should simply understand the following about the two forms of depreciation: 
e Straight-line depreciation With straight-line depreciation, the same amount of depreciation is taken each year. 
Example A $ 1,000 item with a 10-year useful life and no salvage value (the value of an item at the end of its life) 
would be depreciated at $ 100 per year. 
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+ Accelerated depreciation Just know the following. You will not be questioned in further detail. 


</ There are two forms of accelerated depreciation: 
- Double declining balance 
- Sum of the years’ digits 


mJ Accelerated depreciation depreciates faster than straight-line depreciation. 


& Think About It. Here’s an example: $1,000 item with a 10-year useful life and no salvage value would be 
depreciated at $ 180 the first year, $ 150 the second, $ 130 the next, and so on. 


The exam may present information about project selection in the following ways. 


+ Business cases and project selection methods You need to understand that the project must support the 
company’s strategic goals, there is a selection process for projects, and generally how the selection 
process works. 


e Project selection concepts An example is using internal rate of return (IRR) as an answer to a question or 
as a distractor. A concept like this may be provided in the question even when you do not need it to answer 
the question. Read the questions carefully to pick out the relevant data. 


In summary, the project selection process includes the development of a business case and evaluating specific metrics 
as described in this section. The business case describes the business need, the proposed solution, and the expected value 
of the change the project will deliver to the organization and its stakeholders. It includes both tangible and intangible costs 
and benefits of the proposed solution. The business case will influence how you approach every project management 
process covered in this book, beginning with the creation of a project charter — the first of many processes that facilitate 
the success of a project. 


Project Methods and Artifacts 


We briefly discussed OPAs and EEFs at the beginning of this chapter. In this section, we look at them in more detail and 
discuss some methods that are frequently used in project management 


Organizational Process Assets (OPAs) 
Most organizations maintain two types of OPAs: processes, procedures, and policies; and organizational 
knowledge repositories. 


Processes, Procedures, and Policies Over time, organizations develop or adopt processes, procedures, and policies for 
projects. Collectively, these processes, procedures, and policies are referred to as organizational process assets, and they 
apply to aspects of the project such as quality, procurement, and resource management, as well as change control, safety, 
compliance, and more. Artifacts from projects may recommend changes or ways to increase the efficiency of these processes 
and procedures, but they are generally owned by the project management office or other departments responsible for 
organizational governance. 


Organizational Knowledge Repositories The other type of organizational process asset is organizational knowledge 
repositories, which include information on many facets of projects. 

Historical knowledge bases are maintained and updated by every project and made accessible to the rest of the 
organization as part of organization repositories. Historical information can be used to plan and manage projects, thereby 
improving the process of project management and avoiding challenges experienced by past projects. Here are examples of 
historical information: 


e Activities + Risks and risk response plans * Project documents 
+ WBSs + Estimates * Prototypes 

+ Backlogs + Retrospective findings + Baselines 

+ Benchmarks + Resources used * Correspondence 

+ Reports + Project management plans 
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Another aspect of historical information is lessons learned. We will discuss lessons learned in more detail in the 
“Integration” chapter. For now, you need to know that lessons learned, which are created throughout projects, document 
what went right, what went wrong, and what the team would do differently if they had the opportunity to start the project 
over again. Lessons learned from each project become part of the lessons learned repository after project closure. 

Other organizational knowledge repositories include: 

+ Configuration management, including file structure, file-naming conventions, baselines of organizational standards, 

and templates of project documents 

+ Financial data, including budgets and actual costs of completed projects 

+ Issue logs and documentation regarding defects on projects 

e Metrics that may be useful for other projects 

+ Project management plans and baselines, as well as project documents, such as network diagrams, risk registers, and 

stakeholder registers 


When answering questions on the exam, assume the organization has historical records and lessons learned from 
previous projects and that the company has incorporated these records into an indexed organizational knowledge 
repository available to all. 


Enterprise Environmental Factors (EEF) 
EEFs are similar to organizational process assets as they provide context within which to plan the project. However, 
enterprise environmental factors are generally outside the control of the project team. 

Enterprise environmental factors external to the organization include governmental or other rules and regulations 
that apply to the performing organization. Internal enterprise environmental factors include the structure, governance, 
culture, systems, and geographic location(s) of the organization. Resource-related EEFs include the technology and 
resources available for assignment to projects, such as documentation of the skills and abilities of internal and preapproved 
external resources that are available through approved agreements. EEFs related to project management may include a 
resource management system, a procurement system, and a quality management system. 

When answering questions on the exam, assume that the impacts and limitations imposed by enterprise environmental 
factors are taken into consideration during planning and as the work is carried out. i g 

Since EEFs and OPAs contribute to and are influenced by the organizational context in which projects exist, they are 
essential to understanding domain II (Business Environment) in the Examination Content Outline (ECO). For a 
complete view of the project environment, you should also understand that these factors influence and are influenced by a 
set of frequently used tools and techniques available within the organization and developed through individual experience. 


Assumption Log The assumption log is a repository of both assumptions and specifics related to constraints. It is started 

at the time the project charter is developed. Assumptions and constraints are first identified at a high level in the business 

case and project charter. They will receive further attention as the project progresses. The assumption log is an input to 

many project processes, and assumption log updates are a frequent output. 
Assumptions are comparable to expectations, as they may not be entirely 

based on fact. Stakeholders may not realize they are making assumptions, and 

therefore may not articulate them when communicating their requirements. 

Incorrect assumptions introduce risk to the project, so they must be identified and 

managed by the project manager. 


Constraints Constraints are easier to identify than assumptions, as they are 
usually clearly imposed by management or the sponsor. A project manager must 
juggle many things on a project, including project constraints such as schedule, 
cost, risk, scope, quality, resources, customer satisfaction, and any other factors that 
limit options (see figure 3.5). For example, the date a milestone deliverable is due, Customer 
the date by which the project must be completed, and the maximum allowable risk Satisfaction 
a project may have are all constraints. 


FIGURE 3.5 Project constraints 
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Management directly or indirectly sets the priority of each constraint. This prioritization is then used to plan the 
project, evaluate the impact of changes, and prove successful project completion. It is important to evaluate the effect a 
change to one constraint has on another. Changes to the project plan generally impact multiple constraints. 

Take time to really understand the discussion of integrated change control in the “Integration” chapter. Understanding 
the relationship between the constraints and how they impact a project can help you get several questions right on the exam. 


Frequently Used Methods 
There are over 100 tools and techniques in the PMBOK" Guide, and there are many more that we discuss in this book. It’s 
important to use the right method for the right purpose under the right conditions. It is also important to realize methods 
can have multiple applications throughout the project management process. 

You don’t have to be an expert at using all of them, but you do need to understand the purpose of each method. The 
following are categorized by their function. 


Data Gathering If you need to collect input from stakeholders, you can use one or more of the following data- 
gathering methods: 


+ Benchmarking * Cost of quality 

+ Brainstorming + Interviews 

+ Prompt lists e Market research 

e Checklists * Questionnaires and surveys 


e Check sheet 


Data Analysis Depending on the type of data you are working with and the depth of analysis you need to do, you can 
choose from many data analysis methods, including the following: 


+ Alternative analysis + Forecasting 
+ Assumptions and constraints + Performance reviews 
+ Business justification analysis + Reserve analysis 
y Payback period * Root cause analysis 
>/ Internal rate of return * Simulation 
+ SWOT 


y Return on investment g 
+ Trend analysis 


y Cost-benefit analysis «Value stream mapping 


+ Decision tree analysis * Variance analysis 
+ Document analysis + What-if analysis 
+ Earned value analysis 


+ Expected monetary value 


Data Representation Throughout the project, you will gather and generate data from various sources for a number of 
purposes and transform that data to information through data analysis. This category includes options for representing, or 
communicating, data and information. Data representation methods include the following: 


+ Affinity diagrams * Probability and impact matrices 

+ Cause-and-effect diagrams + Release maps 

* Control charts + Scatter diagrams 

+ Flowcharts + Stakeholder engagement assessment matrices 
e Hierarchical charts + Stakeholder mapping/representation 

+ Histograms + Text-oriented formats 


* Logical data models 
+ Matrix diagrams/charts 


+ Mind mapping 


66 


THREE Project Management Foundations 


Decision-Making Throughout the project, you will have to make countless decisions, often with the input of the project 
team. The use of data analysis and representation all support decision making. There are many approaches to decision- 
making, including the following methods, which are used in many project management processes: 


+ Fist of five 
* Multicriteria decision analysis 


* Voting 


Communication As you will read later in this book, a great deal of a project manager's time is spent communicating with 
management, the team, the customer, and other stakeholders. The following are several important communication 
methods and concepts you will use throughout the project: 


e Active listening + Presentations 

+ Appreciative inquiry * Meeting management 

+ Daily standup + Communication methods 

+ Feedback + Communications technology 


Interpersonal and Team Skills Interpersonal and team skills are elements of the art of project management. Closely 
related to the communication methods and concepts listed above, the following skills are essential for project success: 


* Conflict management + Meeting management 

e Cultural awareness e Motivation 

+ Decision-making + Negotiation 

+ Emotional intelligence + Networking 

e Facilitation e Observation/conversation 
+ Influencing e Political awareness 

* Leadership + Team building 


Estimating The project manager is responsible for leading estimating efforts for many aspects of the project, including 
schedule, cost, and resources. The following are common estimating methods you will learn about in this book: 


+ Analogous * Top-down 
+ Bottom-up + Expert judgment 
+ Parametric + Planning poker 


Project Management Information System (PMIS) An organizations project management information system is part of 
its enterprise environmental factors. The PMIS includes automated tools, such as scheduling software, a configuration 
management system, shared workspaces for file storage or distribution, work authorization software, time-tracking 
software, and procurement management software, as well as repositories for historical information. The PMIS is used in 
many planning, executing, and monitoring and controlling processes. 


Expert Judgment Sometimes, the easiest way to get information is to consult experts. Often, those with expertise needed 
by the project are working on the team, or at least within the organization. Expert judgment is a common tool of the project 
management planning processes, although it is not frequently discussed in this book. 


Meetings Meetings are often used in the planning processes of a project, although you will not always see meetings 
discussed in this book as a planning tool. Meetings can be an effective way to get input or feedback from groups of people, 
but they can be overused. The project manager is responsible for determining whether a meeting is worth the time of those 
who would attend it, or if there is a more efficient way to achieve an objective. 


Work Performance Data, Information, and Reports A great deal of data and information is generated, considered, and 
communicated throughout the life of a project, from initial observations and measurements to analyzed content and 
reports. The Process Groups Model: A Practice Guide uses these three terms to identify the stages through which this data 
and information move. 
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Work performance data includes the initial measurements and details about activities gathered during the Direct and 
Manage Project Work process in executing. When monitoring and controlling a project, work performance data is analyzed 
to make sure it conforms to the project management plan. It is also assessed to determine what the data means for the 
project as a whole. The result is known as work performance information. Work performance information can then be 
organized into work performance reports, which are distributed to the various stakeholders who need to receive and 
possibly act on the information. 

For example, let’s say a project team performs their assigned work according to the project management plan. A 
certain activity took 10 hours and was completed on July 21. This is work performance data. The next step is to look at how 
this data compares to the project management plan (in this case, the project schedule). The activity was estimated to take 
12 hours, with an estimated completion date of July 22. The project manager can analyze why this activity took less time 
than planned and what this will mean for the rest of the project. Why was the work completed early? Will this mean 
improved performance for the rest of the project? Did the team follow the communications management plan and notify 
resources assigned to successor activities about the anticipated early completion so they could start their work early? 
Should future activities be re-estimated if similar resources will be performing similar work? 


If the activity was on the critical path and had taken longer than scheduled, a formal change request might have been 
required to adjust the rest of the schedule. 


Project Roles 


Who are the people involved in delivering a project and what should they each be doing? This section will help you under- 
stand the roles of the project manager, agile coach (or team lead or Scrum Master), the product owner, sponsor, team, and 
other stakeholders, as well as functional (resource) managers and program and portfolio managers. Read each role over- 
view and then examine the more specific activities listed for each role. 


understand roles as described here for exam purposes. Use each of these overviews to gain a general understanding 
a of each role on a project and for understanding roles as used in the rest of this book. Responsibilities are further 

elaborated on in the section following this one. Also keep in mind that these overviews and the responsibilities 

lists that follow are not exhaustive but are certainly more than sufficient to help you correctly answer exam 


oe Think About It. Responsibilities vary by organization so think about your own experience, but be sure you 


questions. 


The Project Manager Role 

You no doubt understand that a project manager is accountable for ensuring a project meets its objectives and delivers its 
value and benefits to the organization and its stakeholders. Collectively, of course, the entire project team is responsible for 
making this happen, and other stakeholders have responsibilities to this goal too. But how is the project manager referred 
to in exam questions? 


TRICKS Do not assume that if you recognize a question as describing an agile or hybrid environment, you will not see 


the term “project manager” used in the question or answers. The exam may use the term “project manager” in 
questions regardless of whether it is referring to a predictive, adaptive, or hybrid project. 


Predictive Project Environments The project manager s ‘role includes gathering information to initiate the project, 
ensuring that the projects’ scope is completed on time and within budget. This includes approved changes, which go 
through a formal change control process. This work includes ensuring that the project meets other objectives related to 
communications, stakeholder, risk, quality, and procurement management. The project manager directs and contributes to 
planning and manages the teams work and physical resources while the team works to build the product of the project. 
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Adaptive Project Environments In addition to the agile coach (described next), there is often the need for N 
the project manager on agile projects. For example, the product owner (described next) and the rest of the 


team are focused on project risk as it relates to product features and stories (increments of work broken down Agile 


from features). What happens if the organization moves in a direction that may mean the project will be nos 


cancelled or changed in a significant way? This strategic information is something the project manager pays attention to 
and negotiates within the business environment. The project manager then circles back to the team on what should be 
done on the project moving forward. 


The project manager will also be focused on organizational change management that may result from the project 
while the team is focused on building the product and not these broader changes. 


The Process Groups Model In a predictive environment the project manager is responsible to plan the project with help 
from the team and other stakeholders, and communicate with the project sponsor and other stakeholders who may 
represent the customer or organizational point of view. The project manager is accountable to ensure that the project is 
properly initiated, planned, executed, monitored and controlled, and closed according to the Process Groups model or 
whatever plan-driven methodology an organization uses. 


When you see a question on the exam about a project that clearly uses a plan-driven methodology, think 
“Process Groups.” An answer that fits the scenario in question whose terminology adheres to Process Groups 
model practices is correct over one that appears to fit with agile methods. For example, a plan-driven project 
question willinatiaavena answer that includes the terms “iteration” or “retrospective,” but instead will include 

ems like “phase” or lessons learned. 


The Agile Team Leader Role 
The term “agile coach” is one of several terms used to refer to an agile team’s servant leader, and it is the one 
we will use in this book unless we are specifying a Scrum Master. These are the relevant terms to understand 


Agile 
in the context of the exam: Focus 


+ Agile coach This is as a servant leader whose responsibility is to ensure that the adaptive methods and processes to 
be used on the project are well understood and being followed, and to help the team by removing impediments to 


building and delivering the product of the project The agile coach is also a member of the team where everyone is 
collectively responsible for all stages of the project and the building and delivery of the product. 


° Team lead You may or may not see this term on the exam, but it is generally considered to be synonymous with “agile 
coach.” 


e Scrum Master By definition the term “Scrum Master” is used to refer to the servant leader of an agile project that is 
using the specific agile methodology known as Scrum (see “Common Agile Methodologies” chapter). But in practice 
people mix the terms “agile coach” and “Scrum Master” all the time. So it maybe used on the exam to refer specifically 
to a Scrum scenario, or it may be used as a synonym for “agile coach.” 


TRICKS On the exam, you may see more general terms referring to “agile” projects and methods mixed with those 
OF THE referring to “Scrum Master” or other Scrum-specific terms. PMI may mix and match these terms so don’t let 
TRADE: that distract you from the correct answer! 


The Product Owner Role 

This role was originally associated with Scrum although all types of agile teams may utilize it. The product owner 
(representing value management on the project) is responsible for maximizing the value of the product to the customer 
and return on investment for the organization. They prioritize all work in the backlog to realize the business value of the 
product as quickly as possible. In this respect the development team members take direction from the product owner on 
work item priority, pulling from the top of the backlog (or worklist) that the product owner has prioritized. The team also 
assists the product owner in prioritization by sharing technical requirements, dependencies, and work estimates. 


The product owner is a team member and works with the team daily. While the team is building the product during a 
given iteration (or sprint in Scrum), the product owner is answering questions and getting stories prepared for the 
next iteration. 
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The Product Manager Role 

The term “product manager” is not limited to agile or even project environments and its exact meaning may depend on 
organizational culture. While you are not likely to see a specific question about this on the exam you should understand it 
as distinguished from the product owner role on agile projects. There are usually multiple projects over any one products 
life cycle. A product manager is the liaison between an organizations business strategy, its design and development subject 
matter experts (SMEs), and its customers (internal or external). You can think of the product manager optimizing value to 
the customer and return on investment for the organization over a product’s fife, while a product owner does this in service 
to a particular project. The product manager may lead product owners within an organization or within the needs of a 
specific product, depending on the size and complexity of the organization and its products. 


The Project Sponsor/Initiator Role 

A sponsor is one who represents organizational leadership and supports the project, both financially and to help the project 
manager and team with decisions outside of the project managers and team’s authority. The sponsor partners with the 
team to facilitate their success and can protect the project from unnecessary changes. In procurement situations, the selling 
organization should also have a sponsor. 


The sponsor is accountable to ensure that the project and its product delivers the business value for Pm 
which it was undertaken. In this respect, in agile and hybrid approaches, the product owners’ role is in some ( A J 
ways analogous to that of a sponsor, being responsible for ensuring the project delivers value and benefits. But re 

Focus 


this is a shared responsibility and the project should still have a sponsor in organizational leadership. Notice 
that the product owner was also described as having a role similar in some ways to that of a project manager. 
For the exam, be careful to think about the role being described in the question. While there is overlap, the roles are distinct. 

Think about your organization’s leadership as you read this. Do your projects have sponsors, and do they know what 
their role is on your projects? Someone must serve as a protector of the project and its priorities as long as the project 
continues to meet the organizations strategic goals. 


The Project Team Role 


The project team is a group of people, including the project manager, who will complete the work of the project. Team 
members can change throughout the project as people are added to and released from the project. An agile environment 
may include the concept of keeping stable teams within an organization and bringing projects to the team, while more 
traditional approaches tend to assemble teams as new projects are initiated. 

Generally, it is the team’s role to help plan what needs to be done by creating the WBS or backlog and estimates for 
work packages or activities. Team members complete activities to produce the deliverables represented as work packages 
or features and help look for deviations from the project management plan during project executing and monitoring and 
controlling. In agile environments, team members are responsible for clarifying user stories with the customer so they can 
estimate and plan the releases and iterations, hold reviews and retrospectives, and update the project information using 
tools like Kanban boards and burndown charts. 

On large projects, the project manager may select team members to help perform project management activities. This 
group is known as the project management team. Members of this team must have project management training. For the 
exam the term “project management team” refers to this subset of the team or project team, and it includes the 
project manager. 


The Stakeholder Role 

A stakeholder is anyone who will be impacted by the project or may positively or negatively impact the project. This 
includes the customer or end user, the project manager and team, the project’s sponsor, program and portfolio managers, 
the project management office, functional or operational managers within the organization, other departments or groups 
within the organization (such as business analysis, marketing, procurement, quality, or legal), and external sellers that 
provide services or materials for the project. Questions about the role of stakeholders and how they or their work should 
be managed appear throughout the exam. 
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Stakeholders may be actively involved in the project work or may fill an advisory role. The stakeholders’ role on a 
project is determined by the project manager and the stakeholders themselves. Stakeholders should be involved in planning 
the project and managing it more extensively than many people are accustomed to on their projects. For example, project 
managers should involve the customer in planning and controlling a project. 


~ 


Customer representation is built into agile environments through the role of product owner or value / 
management team, and this is increasingly so on hybrid and traditional projects. The product owner role can 
be filled by someone from the business who is responsible for working with the team to prioritize features. 


A project manager should analyze and manage the needs and levels of influence of stakeholders 
throughout a project and in balance with project constraints. Although the “Stakeholders” chapter includes an in-depth 
discussion of stakeholder management, stakeholders are discussed throughout this book. 


The Functional or Resource Manager Role 

A functional or resource manager is responsible for the human and physical resources in a specific department, such as IT, 
engineering, public relations, marketing, etc., and for working with the project manager to meet the needs of the project. 
As managers of people, facilities, or equipment, functional or resource managers maintain a calendar indicating availability 
of these resources for projects and organizational work. This might involve negotiation if people, facilities, or equipment 
are needed by more than one project at the same time. If there are issues with resources provided by the functional manager, 
project managers collaborate with them to resolve the issues. 

Earlier in this chapter we discussed different organizational structures. The degree that functional managers are 
involved in a project depends on whether the organization has a matrix, project-oriented, or functional organizational 
structure. To avoid conflict, the project manager and functional managers must balance their respective needs regarding 
the use of resources to complete project and operational work. It is generally the responsibility of the project manager to 
manage this relationship by using clear communication and interpersonal and team skills, such as conflict management 
and emotional intelligence. 


The Program and Portfolio Manager Roles 
These roles are not likely to have a big impact on exam questions but they should be understood in terms of the environment 
where projects take place. 


Program Manager This person is responsible for managing a group of related projects, combined into programs to 
provide coordinated control, support, and guidance. The program manager provides oversight to meet both project and 
program goals. 


Portfolio Manager This person is responsible for governance at an executive level of the programs, projects, and 
operational work that make up a portfolio. 


3.4 Exercise 


The following lists contain the responsibilities for each of the project roles. Read these lists carefully and check off 
each responsibility you think you truly understand. Completing this exercise will help you identify gaps so you can 
pay particular attention to understanding those responsibilities as you read the rest of this book. You will want to 
come back to this exercise after you have completed your studies and ensure you can check off all the responsibilities, 
meaning you understand them all in the project context. Getting some exam questions right will depend upon your 
understanding or “who is responsible for what” on a project. 


Note: Each of these lists should give you a good sense of the respective role, but they are not all-inclusive or pre- 
sented in a particular order. 
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Responsibilities Lists by Role 


Now that you understand the fundamentals of each role on a project, use these lists to think more specifically about what a 
person in each of these roles should be doing on a project. 


Project Manager Responsibilities List (in collaboration with the team) 


o 


Oo 


a 0r 0 a € 2 0 0 


Assigned to the project no later than initiating 

Be a servant leader 

Apply project management knowledge and 
interpersonal and leadership skills to achieve 
project success 

Assist the team and other stakeholders 

Identify and analyze constraints and assumptions 
Lead and direct project planning 

Control the project but not necessarily the resources 
Help identify dependencies between activities 

Take action to produce a realistic schedule 

Develop time and cost reserves for the project 
Understand and foster professional and 

social responsibility 

Control the project by measuring performance and 
determining variances from the plan 

Integrate project components into a cohesive whole 
that meets the customer s needs 

Determine the need for change requests, including 
recommended corrective and preventive actions and 
defect repair 

Influence team success by promoting good 
communication, enhancing positive aspects of 
cultural differences, and resolving team issues 
Understand how cultural differences may impact the 
project (including global teams, virtual teams, or 
projects involving multiple organizations) 

Spend more time being proactive than dealing 

with problems 

Perform project closing at the end of each phase and 
for the project as a whole 

Select appropriate processes for the project 


Agile Team Leader Responsibilities List 


o 


mi 


Be a servant leader 


Ensure the processes to be used on the project are 
understood and being followed 


o Remove impediments for the team 


o Help identify requirements 


o Help identify and analyze project constraints 


and assumptions 


o Help identify, analyze, and engage stakeholders 


o Participate in the risk management process 


ci 


Oo 


Write the project charter 

Identify stakeholders, support stakeholder 
engagement, and manage stakeholder expectations 
throughout the project 

Identify and deliver required levels of quality 
Manage project knowledge, including sharing 
lessons learned 

Use rewards and recognition 

Solve problems and remove impediments to the 
teams progress 

Demonstrate ethics and leadership 

Manage and control resources 

Keep team members focused on risk management 
and risk responses 

Coordinate interactions between the project team 
and key stakeholders 

Monitor risk, communications, and stakeholder 
engagement to ensure they’re in conformance 
with requirements 

Finalize and gain approval of the project 
management plan 

Use metrics to identify variances and trends in 


project work, and be responsible for analyzing the 
impact of variances and trends 

Work with the team to resolve variances from the 
project management plan 

Approve or reject changes as authorized, facilitate 
change control, and sit on the change control board 
(Note for agile this is the product owner) 

Ensure professional interactions between the team 
and other stakeholders 


Attend team meetings such as daily standups, 
iteration planning, reviews, and retrospectives 


a Apply ground rules or team charter 


o Help resolve conflict where appropriate 


o Help ensure a common understanding of the project 


and product visions 
Influence the team and environment by facilitating 


communication and enhancing positive aspects of 
cultural differences 
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Product Owner Responsibilities List 


o Represent value management for the team 
and stakeholders 


Help identify and engage stakeholders 
Help identify requirements 


Help identify constraints and assumptions 


m 0 so A 


Prioritize product and iteration backlogs for 
the project 


o Keep the backlog updated 


Project Sponsor Responsibilities List 
During Initiating (or before): 


o Provide high-level scope and requirements 


o Participate in developing the business case and 
vision for the project 


ja 


Guide the process to get the project approved 
o Help to define the measurable objectives 


o Determine (with the customer) priorities between 
project constraints 


o Maintain support for the project 


o Serve as spokesperson for the project, including to 
upper management 


a Facilitate buy-in throughout the organization 


During Planning: 
o Communicate the project vision to the project 
manager and team 
o Provide the project team with time to plan 


a Determine the reports needed by management to 
oversee the project 


o Help identify project risks 


During Executing and Monitoring & Controlling: 
o Support the efforts of the project manager and team 


o Protect the project from outside influences and 
unnecessary changes 


a 


Enforce quality policies 


o Provide expert judgment 


o Help evaluate trade-offs during crashing, fast 
tracking, and re-estimating 


o 


Clarify project vision and project scope questions 
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Attend team meetings such as daily standups, 
iteration planning, reviews, and retrospectives 


Serve as spokesperson for the project 


Help ensure a common understanding of the project 
and product visions 


Participate in the risk management process 


Accept product increments or describe what is 
missing or inadequate during reviews 


Enforce ground rules or team charter 


Provide funding 


May (with the customer) dictate milestones, key 
events, or the project end date 


Help to set priorities between projects 
Advocate for or champion the project 


Provide information that helps develop the 
project charter 


Approve the project charter 


Give the project manager authority as outlined in the 
project charter 


Encourage the finalization of high-level requirements 
and scope by stakeholders 


o Help the project manager and team to balance 


stakeholder priorities 


o May review the WBS 


o Help evaluate trade-offs during crashing, fast 


tracking, and re-estimating 


o Approve the final project management plan 


o Approve, reject, or defer changes, or authorize a 


change control board to do so 


o May direct that a quality review be performed 


o Resolve conflicts that extend beyond the project 


manager $ control 


o Support the project manager in monitoring 


project progress 
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During Closing: 
o Provide formal acceptance of the deliverables (if they 
represent the customer) 


o Enable an efficient and integrated transfer of 
deliverables to the customer 


Team Responsibilities List 

Help identify and involve stakeholders 
Help identify requirements 

Help identify constraints and assumptions 
Help create the WBS or product backlog 


Din oO Oo Bo 


Decompose work packages into activities, or 
decompose stories into tasks 


Identify dependencies between activities 


Provide schedule and cost estimates 


Participate in the risk management process 


Do oe 


Comply with quality and communications plans 


Stakeholder (Customer) Responsibilities List 
Help create the project charter 
Be involved with governance 


Approve project changes 


a oo. oi 


Attend reviews and accept or reject deliverables 


presented; provide feedback 


o Bearisk owner 


o Participate in phase gate reviews 


a Identify issues 


Functional or Resource Manager Responsibilities List 

a Assign specific individuals to the team and negotiate 
with the project manager regarding team and 

physical resources 

o Manage activities within their functional area 

o Participate in project planning until work packages 

or activities are assigned 

a Provide subject matter expertise 

o Participate in risk identification 

a Approve the final schedule during schedule 

development when it involves team or physical 

resources under their control 


o Recommend project changes including preventive 
and corrective actions 


THREE 


Support the collection of historical records from 
the project 


Provide rewards and recognition 


a Apply ground rules or team charter 


a Execute the project management plan to accomplish 


the project scope 

Attend project team meetings 

Recommend project changes, including corrective 
and preventive actions 


Implement approved changes 


a Share acquired knowledge 


a Contribute to the lessons learned register 


Be Bei Po 


Identify constraints and assumptions 

Identify requirements and project scope 

Manage risk 

Help develop the project management plan or the 
backlog and release roadmap 


Help document lessons learned 


Provide expert judgment 


Participate as a member of the change control board 


Inform the project manager of other projects or 
departmental work demands that may impact 
the project 

Sit on the change control board 


Participate in rewards and recognition for 
team members 


Improve resource utilization 

Participate in quality management 

Approve the final project management plan or 
backlog/release roadmap when it involves team or 
other resources under their control 

Assist with issues related to team or physical 
resources under their control 
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Program Manager Responsibilities List 


o Manage related projects to achieve results not 
obtainable by managing them separately 


o Ensure selected projects support strategic goals of 
the organization 


Portfolio Manager Responsibilities List 


o Direct projects and programs that maybe 
largely unrelated 

a Ensure selected projects provide value to 
the organization 


Project Management Foundations 


Provide oversight to adjust projects for the 
programs’ benefit 


Guide and support individual project 
managers’ efforts 


Work with senior executives to gather support for 
individual projects 


Get the best return from resources invested 
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Introduction 


How would you respond if you were asked, “What is a project manager's primary role?” The correct 
answer is: To perform integration management—to pull all the pieces of a project together into a cohe- 
sive whole—the processes, people, and goals for which the project was undertaken. This is so much a 
part of a project manager's job that it is arguably the reason for the project manager 5 existence in an 
organization and on a project. 

All stakeholders have the common purpose of achieving project objectives efficiently and in 
compliance with scope, schedule, and cost baselines as well as agreed-upon quality requirements, 
while effectively managing uncertainty. While the work is being done: 

+ Team members are concentrating on completing the work packages or stories. 

+ The project sponsor is supporting the project and the team, protecting assigned resources from 
being diverted to other activities within the organization, and acting as a management consultant 
to the project manager. 

+ The project manager is integrating all project components—the team and all other stakeholders, 
project constraints, processes, and internal and external elements that may affect the project both 
internal and external to the project and the organization. 

+ The project manager is also communicating within the organization, usually with management, 
to integrate the project's needs with those of related portfolios and programs within the larger 
organization, and within society at large. 


This difficult and challenging job requires a project manager to have technical project management 
skills, of course, but they must also be an accomplished innovative thinker and collaborative leader and 
possess empathy and business savvy. 


Think about integration as balancing all project activities with each other while at the 
TRICKS gr ea pre) 

Mji same time being a project ambassador for all stakeholders: The team, customers, 
IE management, government regulatory bodies, and any others involved. 


Keep in mind that project management activities do not happen independently of one another. 

Example To complete an estimated budget, factors must be taken into account such as time and 
resources needed to create individual work packages or stories (i.e. product increments), available 
resources, and the costs of managing identified risks. The draft budget must also be reconciled with 
financial considerations within the larger organization before it is approved. 

Read this chapter carefully. Integration management can be a difficult content area because it is 
something we do as project managers, but we may not often think about it as a separate process, with 
everything that process entails. 
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Integration Management Overview 


As mentioned in chapter 1, we will include here an illustration showing select Examination Content Outline (ECO) tasks 
alongside PMI’s Process Groups model for that process. This will help you understand an overall process - in this case, In- 
tegration Management. Again, the PMBOK* Guide domains listed here are ones we think fit well into the discussion of the 
process, but we will delve into the PMBOK? Guide in more detail in chapter 18. 

For now, focus on the processes represented by the Process Groups model, the ECO tasks, and the associated agile 
and hybrid concepts. 


The Examination Content Outline and Process Groups Model 


Think About It. In the ECO, domain II has seven tasks most closely associated with integration management in 
the Process Groups model. Some tasks might not translate as easily, but in reality, integration and the tasks 
associated with it are some of the most important tasks of a project manager. If you haven’t done so already, take 
out your copy of the ECO and review these domain II tasks and their enablers as you review this page of this book. 


Example Task 1: “Execute project with the urgency required to deliver business value.” Wouldn’t you say that is 
exactly what we are doing all the time as project managers? We are executing the project with the urgency required to 
deliver the business value to the organization and its customers, for which the project was undertaken. 

Task 1 is also related to directing and managing project work, managing project knowledge, monitoring and controlling 
project work, change control, and closing project phases and the project—all processes in the Integration Management 
area of the Process Groups model. 


Domain II Integration Management 
Taski Domain 2.1 
Execute project with the urgency required to Develop Project Charter — Initiating Stakeholders 
deliver business value 5 ee 
Develop Project Management Plan — Planning oman 2s 
Task 9 Team 
Integrate project planning activities Direct and Manage Project Work —> j 
Executing Domain 23 
Task 10 Manage Project Knowledge —I Development Approach and Life Cycle 
Manage project changes p 
Monitor and Control Project Work —i Monitoring Domain 2.4 
Task 12 Planning 
Manage project artifacts Perform Integrated Change Control —| ® C°nto.ing 
Domain 2.5 
Task 13 Close Project or Phase — Closing Project Work 
Determine appropriate project E Pae 
methodology/methods and practices lomain 2.1 
Delivery 
Task 16 X 
Ensure knowledge transfer for project continuity Domain 2.7 
Measurement 
Task 17 i 
Plan and manage project/phase closure Domain 2.8 
Uncertainty 


or transitions 


Now think about the other domain II ECO tasks as they relate to what is in the Process Groups model: 

+ Task 9: Integrating project planning activities starts in Initiating with developing the project charter (and stakeholder 
analysis and development of the stakeholder register). 

+ Task 13: Determining appropriate methodology and practices is just like the first activity in the Planning column of 
Rita’s Process Chart™ (in the “Project Management Foundations” chapter). While not directly listed as an integration 
process in the Process Groups model, it is what the project manager needs to start creating the project management plan. 

+ Tasks 9 and 12: The first of these is obvious—task 9. The project manager needs to integrate the many planning 
activities to develop the project management plan (a project artifact). The project management plan is a series of plans 
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configuration management, and change management. These plans are started separately but as each plan matures it 
requires integration with the other plans, since each project constraint is interdependent with and can affect all others. 

+ Task 10: Project changes will be managed according to the plan for change management. 

+ Task 16: As the project manager and the team learn throughout the project, the project manager will need to see that 
this knowledge is shared for the benefit of the project and documented so the project artifacts can benefit the 
organization in the future. You can also map task 16 to the Process Groups model processes Direct and Manage 
Project Work and Manage Project Knowledge. 

e Task 17: Can you see from the wording of this task that it carries the same responsibility as Close Project or Phase in 
the Process Groups model? 


Figure 4.1 is a visualization of the integration management processes from the Process Groups model. Remember 
that for each chapter in which the domain II processes are discussed, we will use the Process Groups model to help you 
understand the general process. Since the Process Groups model was created based on managing plan-driven projects, we 
also explain the different methods agile practitioners use to get to the same goals. It is worth repeating: The goal is to work 
to meet project requirements with the urgency needed to deliver the benefits and value for which the project was selected 


and undertaken. 


Key 
Continuous change control 
is consistent with all 
approaches 


Change prompts a process 
( * to be reiterated through 
progressive elaboration 


or agile methods 
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` 
` 
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` 
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FIGURE 4.1 Integration management process 


Besides the five process groups, the Process Groups model identifies certain areas that work is focused on (most of 
which are project constraints). These categories are integration, stakeholders, communications, resources, scope, schedule, 
cost, quality, risk, and procurement. Figure 4.2 shows the relationship between these categories and process groups from 
the Process Groups model. With figure 4.2 you can easily see where a project manager ’s activities are focused by category. 
For example: 

+ All project management categories have project management processes in planning and monitoring and controlling. 

* Scope, schedule, and cost show no project management activity because it is the team that is executing the work to 

build the product of the project, while the project manager monitors and controls all project work. 

+ Stakeholder engagement has no process for closing because when a project or phase is closed, the project manager has 

already managed the stakeholder engagement for that phase or the project. 

+ Did you notice that Integration Management is the only project management category that has processes occurring in 

all process groups? The project manager is always integrating. 
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We encourage you to return to figure 4.2 after you have had the opportunity to study the process-related chapters in 
this book. The process-related chapters help you with the details while this figure helps you understand the big picture. 


Process Groups 


Monitoring 
Initiating Planning Executing & Controlling Closing 


oatogorieg 


FIGURE 4.2 The relationship between the process groups and the major project management process categories 


Develop Project Charter 


The Develop Project Charter process includes using all the information known about 
a project from the project selection process to achieve an approved (signed) project 

charter. The project charter authorizes the project to continue. This process also in- 

cludes the creation of an assumption log, which is an artifact of developing the project 
charter. The assumption log is updated throughout the project, as assumptions and 
constraints change and new assumptions are uncovered. 


Creating the Project Charter 

The purpose of the charter is to plan the project at a high level to assess whether it is 
feasible within the given constraints. Detailed planning begins only after the charter is 

signed. In project initiating, the project manager meets with key stakeholders to refine 
the high-level objectives, requirements, scope, risks, assumptions, and other 

constraints. Then, the information gathered is used to confirm the project is realistic, 
aligns with the organizations strategic goals, and is likely to deliver the anticipated 

benefits and value. Additional resources (time and money) are spent only after the project charter is approved. 

The project manager most often creates the project charter, but it is issued (signed off on) by the sponsor during 
initiating. The charter should be broad enough that it does not need to change as the project progresses. Changes to the 
project charter, beyond initiating, should call into question whether the project should continue. 

Projects that include agile or hybrid approaches tailor charter documents. For example, a project charter 
may articulate that there is more uncertainty about requirements or the product deliverables at the beginning 
of the project. How the governance of the project is explained may also contain different information. For Agile 
instance, instead of a formal change control board a project’s product owner may typically have the authority Foci 
to make decisions regarding change management and prioritizing requirements. 
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4.1 Exercise 


Test yourself! Answer the following questions in your Exercise Notebook. 


+ What does the project charter do for the project and the organization? 


+ Why is it so necessary? 


Answer 


The project charter describes the project goals and objectives and defines how success will be measured. For the 
exam, know that the charter at a minimum does the following: 


+ Formally authorizes the existence of the project, or establishes the project 

e Gives the project manager authority to commit resources to the project 

+ Provides the project objectives, high-level requirements, and success criteria 

+ Defines roles and responsibilities at a high level 

e Clarifies a common understanding of the project’s major deliverables and milestones, between the sponsor 
and project manager 


+ Links the project to the ongoing work of the organization 


On the exam, assume it is the project charter that gives the project manager the authority on the project (to use the 
organizations ‘resources to the projects’ needs). This authority helps the project manager get work done through others 
who do not directly report to them. 

The process of creating the charter uncovers the assumptions recorded as the start of the assumption log. These 
assumptions will later be updated or addressed in the detailed requirements gathering, scope definition, and risk 
management efforts. Can you see that the creation of a project charter should address and influence all the project 
management constraints? Aside from the assumption log and the charter, you should have the following documented in 
their respective project artifacts: 


* Identified and analyzed stakeholders 


* Defined project objectives, constraints, and success criteria 
* Confirmed high-level requirements 
* Preliminary product scope definition 


+ Documented initial risks and issues 


Some of the tools and techniques that can be used during this process include data gathering (interviews, 
brainstorming, focus groups, etc.), conflict management, and meeting management. During meetings with the sponsor 
and key stakeholders, the project manager can obtain needed information and work with experts to understand and 
address organizational strategy and develop measurable project objectives. 

Note: The following charter example is not an exact template; a charter should be tailored to meet the needs of the 
business and project. This example is meant to show you the types of sections that maybe included and what those sections 
may summarize. Also note that this charter refers to attached documents that are not included in this example. 
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Project Charter 


Project Title and Description (What is the project?) Upgrade the Payroll Systems 

Were a large, multinational organization with more than 20,000 employees, so human resource management is critical to 
our success. To more efficiently compensate our employees, we want to replace or upgrade the employee payroll systems 
to better reflect the changing nature of our workforce. Employees now work in various locations (offices and homes) 
around the world, work simultaneously for multiple business units, and have more varied work schedules than ever 
before. Current geographically focused payroll systems are not integrated, are inflexible, and require significant clerical 
time to maintain them manually. With the existing systems, consolidated corporate reporting and analysis is expensive 
and inefficient. 


Project Manager Assigned and Authority Level (Who is given authority to lead the project, and can they determine, manage, 
and approve changes to budget, schedule, staffing, etc.?) 

Isaiah Higgins will be the project manager for this project. He may request any team members he sees fit and will work 
with resource managers to secure the needed resources. He has signature authority up to $10,000. Ashley Chan is 
assigned as assistant project manager. 


Business Case (Why is the project being done? On what financial or other basis can we justify doing this project?) 
Administering payroll currently costs $2.4 million annually along with the unmeasured costs of procedural inefficiencies. 
The industry average payroll processing costs for a global company our size is $100 per employee per year, or $2 million 
overall per year. Anticipated savings of $400,000 per year (assuming a three-year payback period) justifies the approval of 
this project. See the detailed business case attached to this charter. 


Resources Preassigned (How many or which resources will be provided?) 

The corporate payroll processing group will be closely involved in this project, along with the payroll specialists who 
work in our local offices. A senior team of business analysts, enterprise architects, and software designers has been iden- 
tified for the initial research and analysis phase. Procurement and legal representatives will be involved in seller contract 
processes, including development of RFPs and contracts when deemed necessary. English will be the primary project 
language; local language experts will be involved to ensure country-specific regulations and laws are understood. Other 
required resources must be identified and negotiated for by the project manager. 


Key Stakeholder List (Who will affect or be affected by the project [influence the project], as known to date?) 

Attached is a list of stakeholder groups that will be impacted by this project. It includes all employees, divided into payees, 
corporate management, legal, procurement, and payroll administrators. It also includes outside representatives of gov- 
ernment taxing authorities, benefit providers, and suppliers of payroll-processing solutions. 


Stakeholder Requirements as Known (Requirements related to both project and product scope.) 


Req. Number High-Level Requirements 


RI Pay employees based on the agreed-upon rate/salary on the agreed-upon schedule. 

R2 Adhere to country-specific government requirements related to tax withholding and 
payment schedules. 

R3 Adhere to state, province, county, or other local government requirements related to tax 
withholding and payment schedules. 

R4 Allow the company to provide benefits for employees as approved by the Board of Directors. 

R5 Allow the company to collect benefit premium payments from employee pay as agreed to by 


each employee. 


R6 Keep all employee data confidential, secure, and archived as required by law in each jurisdiction. 
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High Level Product Description/Key Deliverables (What are the key product deliverables that are wanted and what will be the 
end result of the project?) 
The result of this project should be one or more systems that support payroll processing for all employees, at or below the 
industry average cost. Specific desired features include: 
* The systems should allow direct deposit of employee pay into any financial institution in the world, along with 
notification of deposit via email or text message to any device. 
+ Workers should be able to change their address, number of dependents, tax withholding parameters, and benefit 
characteristics via a website at any time from any location. 
+ The systems must support consolidated management and reporting of corporate payroll processing, plus government 
mandated reporting and payments. 


High-Level Assumptions (What is believed to be true or reliable in the situation? What do we believe to be the case but do not 
have proof or data for? See details in the assumption log.) 


+ There are payroll applications available that support the countries in which our employees are located. 
+ The average cost of $ 100 per employee per year is accurate for our industry. 
+ Each employee reports their primary residence in just one country for tax reporting purposes. 


+ We have internal resources available to evaluate and do the work assigned. 


High-Level Constraints (What factors may limit our ability to deliver? What boundaries or parameters will the project have to 
function within?) 
* The system must be able to comply with all international payroll rules and perform direct deposits globally. 
+ The solution and the supporting systems must be able to maintain organizational information security standards 
that meet or exceed individual country standards. 
+ Year-end tax reporting must be completed by the new system in the year of the implementation (payroll data must 
be converted). 


+ Summary milestone schedule: Due no later than October 6,20XX 


* Preapproved financial resources: $1,200,000 


Measurable Project Objectives (How does the project tie into the organization’s strategic goals? What project objectives 
support those goals? The objectives need to be measurable and will depend on the defined priority of the project constraints.) 


The main objective of this project is to decrease costs by at least $400,000 annually. A second objective, which supports 
the first, is to increase productivity for new employees and payroll processing employees. 


* Decrease payroll processing costs by 15 percent in two years by decreasing manual clerical processes. 
+ Decrease the duration of the new worker onboarding process from an average of 5 business days to 2 business days 
within 18 months. 


Project Approval Requirements (What items need to be approved for the project, and who will have sign-off authority? What 
designates success?) 
Approvals for this project include: 

* Decision to purchase application software to support the payroll systems (VP of Operations) 

* Choice of seller application package (Director of HR) 

+ High-level design of the new systems (Director of HR) 


e Global transition plan for new systems rollout (VP of Operations) 


Overall Project Risks (Overall potential threats and opportunities for the project) 
+ Because of the complexity of employee pay calculations and the large number of employees, we may have errors in 
employee payroll during implementation of the new systems. (High impact) 
+ Because of the number of localities supported and differing regulations, we may have errors in government tax 
payments and regulatory compliance during implementation of the new systems. (High impact) 
* Because of the volatility in the software application marketplace, we may select an unreliable seller for delivery of 
the payroll-processing applications. (High impact) 
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Project Exit Criteria (What needs must be met so that the project manager will be able to close or terminate the project or 
phase?) 
+ Anew payroll processing system that meets the project objectives and requirements and incorporates all key 
deliverables described herein will be delivered within defined cost and budget constraints. 
* Or, if it is determined that the project objectives of cost saving cannot be met, the project manager will recommend 
termination of the project. 
* Or, if it is determined that another solution will better meet the organizational needs, the sponsor should be notified 
for closing approval, and a business case will be developed for the new solution. 


Project Sponsors Authorizing This Project 


Muhammad Chauhan, Executive Vice President Jessica Bouchard, Director of Human Resources 


Develop Project Management Plan 


The project management plan describes the project’s development approach 
and life cycle, and how the project will be executed and controlled. It identifies 
when project management reviews will be needed and contains the perfor- 
mance measurement baseline (scope, schedule, and cost baselines). It contains 
and integrates plans for managing the following categories: 


* Scope + Resources 

+ Requirements + Communications 

+ Schedule e Risk 

+ Cost * Procurement 

* Quality + Stakeholder engagement 


Let’s discuss then, what is a management plan. 


Management Plans 
Management plans document the strategy and approach for managing the 
project and the processes, related project constraints, and other major areas 


needing management and integration, like communications and stakeholder 
engagement. Plans include processes, procedures, practices, and standards the team will follow to ensure consistent results. 

When creating a management plan, ask yourself, “How will I define, plan, manage (execute), and control scope (or 
schedule, cost, quality, etc.) for the project?” “How will closing phases be performed, if that’s part of the overall project?” 
You think ahead, and document how you will plan and manage for each project management category based on its 
particular needs. 


Planning Components 
Management plans must be tailored to each project, including the format and level of detail needed at each stage of 
planning. If you don’t create management plans for your projects, this area of the exam may be difficult for you. Let’s 


consider an example of how you would address cost management. 


Example Let’s say you are planning for the cost on a project. You need to address questions such as: 


e How will you ensure all costs are identified + What estimating methods will you employ? 
and estimated? + What level of accuracy is appropriate ? 
+ Who will be involved in estimating costs? * How will funding and cost constraints be considered 
+ What cost estimating methods will you use? when establishing the budget? 
+ What historical records, processes, and + What data, metrics, and measurements do you need 
organizational requirements will need to be used for planning cost? 
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Agile and hybrid environments may not have these plans documented as separate artifacts. However, this 
does not mean the planning of these attributes is absent. Rather, they are incorporated into other artifacts. For 
example, scope, schedule, and risk management plans are often incorporated into a product backlog and ao. 
release roadmaps. These artifacts show the plan for project work, inclusive of risk response decisions and 
when product increments are planned for delivery. 


Executing Components 

The executing portion of a management plan focuses on the processes and procedures for doing the work. Some 
management categories, such as cost management, won’t have separate executing processes for the project manager. This 
is a function of integration management. 


Example The executing component of a cost management plan answers questions such as: 
+ What cost data are needed? 
+ Who is responsible for gathering the data? 


* Where will the raw data be captured that will later be used in monitoring and controlling? 


Monitoring and Controlling Components 

The monitoring and controlling components of a management plan define the processes and procedures to measure 
project progress, compare actual project results to what was planned, and determine how to handle variances that require 
a change. 


Before you read further, spend some time imagining what management plans for the different categories (scope, 
schedule, quality, resources, communications, risk, procurement, and stakeholder engagement) might contain. Many 
project managers don’t realize how big their knowledge gap is regarding management plans until it finds them on the exam. 
Don’t let this happen to you! 


Here is a trick to understanding management plans for the exam. Know that management plans look forward 
in time and that there are management plans for all the project management categories. There are also these 
management plans: 


* Change management plan 
* Configuration management plan 
+ Requirements management plan 


When you are taking the exam, assume the project manager has created each of these management plans. If a question 
refers to a problem on a project, the answer might be for the project manager to look at the management plan for that 
aspect of the project to see how the plan says to handle such a problem. For example, when the work is being done, the 
project manager might refer to the cost management plan to see how costs are to be measured and evaluated. 


The Project Management Plan 

The project management plan integrates all the individual management plans into a cohesive whole, creating a centralized 
artifact to describe what is involved in the project. The overall project management plan also includes the baselines for the 
project. This means a project management plan is a set of plans and baselines (not just a schedule). The key components of 
the project management plan are discussed in the following sections. Remember the agile and hybrid differences we 
discussed in the previous section, and think through how an adaptive approach may tailor any of the following plans and 
project management components. 


85 


Integration FOUR 


Project Life Cycle 


The project life cycle describes the phases of work on a project required to produce the deliverables (for example, 
requirements, design, code, test, implement). Project life cycles range from plan-driven to change-driven. 


Development Approach 


Development approaches to produce the project deliverables range from plan-driven to change-driven. 


Management Reviews 


Milestones will be built into the project management plan, indicating times when management and stakeholders will 
compare project progress to what was planned and identify needed changes to any of the management plans. 


Tailoring 
Think about the science of project management for a moment. Would you want to use everything in the Process Groups 
model to the same extent on every project? No. A project manager should determine what processes and the extent to 
which processes are to be used, based on the needs of the project. Tailoring the processes and the project work is part of 
leveloping the project management plan. 

Although we don’t always use the word “tailoring” or call tailoring out in separate sections, we talk about tailoring 
throughout this book. Be aware as you are reading: Everything you do as a project manager is a creative use of the knowledge 
and skills you have and the methods available to you. This, in essence, is tailoring. 


Individual Management Plans 
These are the management plans for scope, schedule, cost, quality, resources, communications, risk, procurement, and 
stakeholder engagement. (The individual management plans are discussed in the Process domain chapters of this book.) 


The Performance Measurement Baseline 

The project management plan includes scope, schedule, and cost baselines, against which the project manager will analyze 
and report project performance, Created during planning, these baselines are collectively referred to as the performance 
measurement baseline. The following are the elements included in each baseline: 


* Scope baseline The project scope statement, work breakdown structure (WBS), and WBS dictionary 


* Schedule baseline The agreed-upon schedule, including the start and stop dates for each activity, and 
scheduled milestones 


* Cost baseline The time-phased cost budget (the spending plan indicating how much money is approved for the 
project and when the funds are required and will be available) 


The project manager and team will watch for deviations from the baselines while the work is being done. If a deviation 
is discovered, they will assess whether adjustments can be made to bring the project back in line with the baseline. These 
adjustments might involve submitting a change request for corrective or preventive action or defect repair. 

If minor adjustments will not correct a deviation, a request to change the baselines might be necessary. A substantial 
part of managing a project beyond planning is making sure the baselines are achieved, which in turn helps ensure the 
sponsor and the organization get the complete benefits of the project they chartered. Therefore, as a project manager, your 
ability to not only plan a project but also to control the project and get it completed as planned is very important. 

On plan-driven projects, requested changes to the baselines are evaluated and approved in the Perform Integrated 
Change Control process, discussed later in this chapter. Baseline changes are serious and the evolution of the baselines 
should be documented to show when and why changes were made. Baselines are mentioned frequently on the exam. Make 
sure you understand the concepts described here, including what the project manager $ approach should be to the projects 
baselines and any changes to those baselines. 


TRICKS Deviations from baselines are often due to incomplete risk management. Therefore, if the exam asks what to 
OF THE do when a project deviates significantly from established baselines, consider that the correct answer may be 
HMA the one about reviewing the projects risk management process. Many project managers are not aware of this. 
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Requirements Management Plan 

Part of the scope management process (described in the “Scope” chapter) involves defining and planning for stakeholders’ 
needs, wants, expectations, and assumptions to determine the requirements for the project. The requirements management 
plan defines how requirements will be gathered, analyzed, prioritized, evaluated, and documented, as well as how the 
requirements will be managed and controlled throughout the project. 


Change Management Plan 


Controlling a project to the baselines and the rest of the project management plan is so important that the project manager 
needs to think in advance about where there might be changes and what to do to limit the negative effects of changes. Are 
you this focused on change management on your projects? In a plan-driven environment, the project manager needs to 
plan to minimize changes and prevent unnecessary changes. They also need to proactively look for needed changes, thereby 
solving issues before they have a major negative impact on the project. 

The change management plan describes how changes will be managed and controlled, and may include: 

+ An outline of how changes will be managed and controlled 


+ Change control procedures (how and who) 


+ Approval levels for authorizing changes 

+ The creation of a change control board (described later in this chapter) to approve changes, as well as the roles and 
responsibilities of those on the board 

+ Who should attend meetings regarding changes 

+ The organizational tools to use to track and control changes 

+ Information on reporting the outcome of change requests 


+ The emergency change process 


In agile environments the team expects change, which is why this type of project planning is described as r~ 
adaptive. Project and product requirements, including risk management activities, are prioritized in the ( A } 


backlog in order to maximize the team’s ability to deliver value through incremental delivery of product f Agile 
Focus 


features while maintaining an established schedule and budget. 


Configuration Management Plan 

The configuration management plan defines artifact naming conventions, a version control system, and document storage 
and retrieval processes and locations. This plan details how the project manager will manage changes to the documentation, 
including which organizational toolswill be used in this effort. Configuration management is essential to ensure all relevant 
stakeholders are aware of and have access to the latest versions of the project management plan components. 


Putting the Project Management Plan Together 

The project manager and the team create the project management plan by completing the activities described in the 
Planning column of Rita’s Process Chart™, Once the project management plan is complete, the sponsor or key stakeholders 
review and approve it 

The Develop Project Management Plan process must result in a plan that is bought into, approved, realistic, and 
formal. In other words, the project management plan needs to be agreed to by the key stakeholders involved in the project, 
it needs to be formally approved, everyone needs to believe the project can be done according to the plan, and it needs to 
remain a formal artifact that is revised and used throughout the project. If this is a new concept to you, make sure you 
spend time thinking about how to accomplish this in the real world. 

On an agile or hybrid project initial plans will be deliberately light and progressively elaborated. Planning FaN 
takes the form of release and iteration planning and early iterations of product building provide clarification A) 
and additional information. Agile methods also encourage shifting planning responsibilities to the team, with ? Agile 
scope prioritization by a product owner. The product owner is part of the team and they will, along with the 
project manager, help ensure that the project plan is viable via the prioritization of the backlog and through a timephased 
product roadmap. Plans and processes may be less formal than those for a plan-based project but they are made and 
controlled with as much rigor. 
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Through initiating and planning, let’s see how everything connects so far by looking at figure 4.3. 


A need is identified: “What do | want?” 


Sono Project manager Project manager 
Wena Business helps identify Sponsor and team develop 
product —_ documents stakeholders and signs and the project 
owner documents the issues management 
charter. the charter. plan. 

Company 

culture and 

existing Sponsor 

systems 

procedures, 

and historical The project management plan 

information is bought into, approved, realistic, 

e and formal. 


FIGURE 4.3 Project initiating and planning 


Once the project management plan has been completed, the project manager uses it as a tool to help 
manage the project on a daily basis. Although it may evolve over the life of the project through progressive 
elaboration or approved changes, the project management plan in a predictive environment is designed to be Agile 
as complete as possible when project executing begins. In adaptive environments the frequency of progressive foca 
elaboration related to planning and requirements elicitation is more frequent. 


4.2 Exercise 
Test yourself! In your Exercise Notebook, make a list of the specific actions required to create a project management 
plan that is bought into, approved, realistic, and formal. 


Answer 
Some possible answers include: 


e Select the best life cycle and development approach for the project 

e Agree on processes to report, control, incorporate, and communicate changes 

e Analyze the stakeholders’ needs, wants, expectations, and assumptions 

e Capture the project requirements as completely as possible 

e Work with team members to estimate the project 

e Give team members a chance to approve the final schedule that converts the team’s activity estimates into 
a calendar schedule 

e Get resource managers to approve the schedule and confirm when their resources will be used 

e Work through iterations of the plan (for example, update the work breakdown structure after completing 
risk analysis) 

e Create the necessary supporting project documents (for example, the stakeholder register). 

e Apply risk reserves to the project schedule and budget 

e Let the sponsor know if any of the project requirements that were outlined in the project charter cannot 
be met 
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e Perform schedule compression (crash, fast track, change scope or quality, etc.), and present options to 
the sponsor 
+ Look for impacts on the project from other projects 
+ Make sure the approach and processes are consistent with the PMO and/or program management plan if 
the project is part of a program 
If you included most of the answers from the exercise, you are in good shape. But why is it so important to have a 
project management plan that is realistic and that everyone believes can be done? Because while the work is being 
done, progress against the plan is measured to see how the project is going. The constraints agreed to as the project 
management plan is approved must be met. 


So when you think of the project management plan, think of all the facilitations, meetings, sign-offs, interactions with 
other projects, conflict resolution, negotiations, schedule compressions, etc——everything required to bring the plan to the 
point of being bought into, approved, realistic, and formal. 


Project Documents 
The term “project documents” refers to any project-related documents that are not part of the project management plan. 
They include artifacts like the following (although not an exhaustive list): 


e Project charter * Schedule and + Agreements 

+ Assumption log resource calendars e Contracts 

+ Issue log * Reports (quality, risk, etc.) + Statements of work 
+ Estimates + Resource requirements e Risk register 

+ Lessons learned register * Requirements documentation * Forecasts 

* Team charter * Change log * Quality metrics 


While the sponsor and/or key stakeholders will see and approve the project management plan, most project 
documents (excluding the project charter, agreements, contracts, and statements of work) are created and used by the 
project manager and team and do not require sponsor approval. 

Due to the iterative nature of planning and the nature of the work throughout the rest of the project, project artifacts 
are updated frequently. Though this book will not cover these updates as an output of every process, know for the exam 
that project documents updates are an output of many project management activities. 

Example Midway through the project the project manager and team agree that a particular risk that has not occurred 
is no longer likely to occur. The risk register and other risk artifacts are updated and the funds in the contingency reserve 
for that risk are theoretically no longer available to the project. 


Project Management Plan Approval 

Since the project management plan is a formal document, it requires formal approval by management, the sponsor, the 
project team, and other key stakeholders. Formal approval means sign-off (signatures). If the project manager has identified 
all stakeholders and their requirements and objectives, included the appropriate project and product scope in the plan, and 
dealt with conflicting priorities in advance, getting the project management plan approved should be relatively 
straightforward. 


Kickoff Meeting 
Before the Develop Project Management Plan process is considered complete and project executing begins, a kickoff 
meeting should be held. This is a meeting of the key parties involved in the project to announce the start of the project, to 
ensure everyone is familiar with its details—including objectives and roles and responsibilities—and to ensure a 
commitment to the project from everyone. In addition to introducing those involved in the project, the meeting may 
review such items as milestones, risks, the communications management plan, and the meeting schedule. 

While kickoff meetings are common on agile projects, the project information exchanged at this meeting y 
remains high-level. Detailed information about product features and product increments emerge as release (A) 
and iteration planning continues, followed by iteration reviews with the customer and/or management PAA 
representatives in iteration review meetings. Kocs 89 
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Direct and Manage Project Work 


This process represents the integration aspect of project executing—the part of the 
project where the team does the work to build the product of the project. In Direct 
and Manage Project Work, the project manager integrates all the executing work 
into one coordinated effort to accomplish the project management plan and pro- 
duce the deliverables. In addition, Direct and Manage Project Work involves gath- 
ering work performance data, creating and using the issue log, requesting changes, 
and completing work resulting from approved change requests. 

These tasks involve managing the work and keeping people engaged. 
Ultimately, it’s about being of service to the team to help them get the work 
completed, ensuring a common understanding of the project among stakeholders, 
and keeping everyone informed by documenting and facilitating issue resolution. 
The project manager also facilitates meetings and technical discussions, and on 
plan-driven projects uses a work authorization system (part of the project 
management information system or PMIS) to keep the team and functional 
managers informed of upcoming work assignments and milestones. The project 
manager also removes impediments for the team, works on process improvement, 


and informs other departments within the organization how the project may affect 
their work. 

Integration management requires project managers to keep all constraints in mind at all times and to properly look at 
how issues relating to one constraint affect others. For example, scope management issues can affect quality metrics and 
resource management. 


TRICKS If you have never used a work authorization system, imagine a large construction project with hundreds of 
OF THE people working on the project. Can you have a plumber and an electrician show up to work in one small area 
IMJ at the same time? No. Remember that a project is planned to the level of detail needed for that project. To 
handle these types of situations, a work authorization system makes sure work is only started when a formal 
authorization is given. In many cases, this tool is a company-wide system and not created just for the project. The term 
“work authorization system” could appear in a question on the exam or be included as an answer choice. 


Depending on the needs of the project and its development approach, the use of meetings as a method can range from 
informal standup sessions to structured meetings with an agenda that focuses on a specific aspect of the project. Other 
meetings may be related to project updates, lessons learned, upcoming project activities (like an iteration planning 
meeting), and risk management or change control. 

The Direct and Manage Project Work process can be illustrated as shown in figure 4.4. The primary outputs of this 
process include completed deliverables along with any new work performance data and change requests. Other outputs are 
updates to organizational process assets and project artifacts. 


Direct and 
Manage 


Project Work 


FIGURE 4.4 Direct and Manage Project Work process 9 0 
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4.3 Exercise 


What are some of the most likely project artifacts to be updated as an outcome of the Direct and Manage Project 
Work process? Write the answer in your Exercise Notebook. 


Answer 
Project artifacts that may be updated as a part of this process include the following: 
+ Project management plan 
+ Requirements documentation 
e Activity list 
+ Assumption and issue logs 
+ Lessons learned, stakeholder, and risk registers 


TRICKS Keep in mind as you read the rest of this book, that for every process there are project artifacts that are likely 
(0): t0 be updated as the project progresses. 


Manage Project Knowledge 


Think of the tremendous amount of knowledge required to properly plan and exe- 
cute a project. Project managers can benefit from the knowledge base the organiza- 
tion has accumulated over time, particularly from the experiences and discoveries 
of others on past, similar projects. The Manage Project Knowledge process requires 

each project to actively contribute to that knowledge base. This includes sharing 
new processes, successes, etc., internally within the project, as well as making that 
knowledge accessible throughout the entire organization. 


Information and Knowledge Management 

Successful and consistent knowledge and information sharing contributes to a 
productive work environment and increases the ability of project teams to achieve 
project and organizational objectives. Successful knowledge management requires 

an organizational culture of trust in which the project manager and stakeholders 
exchange knowledge without fear of judgment. The project manager needs to 
foster an environment that will support collaboration and knowledge sharing. As an example, discussion forums and other 
interactive online tools may help to facilitate this type of environment. 


New knowledge that is important to share often involves experiences that did not work out as planned. The project 
manager can learn from each unidentified stakeholder, each missed risk trigger, and each unrealistic schedule component. 
Sharing such information and possibly saving another project or person from a similar issue is invaluable. This philosophy 
has evolved in the traditional project management world and was built into agile project management practices since 
people started using agile. 

Knowledge management includes two distinct types of knowledge—explicit and tacit. 


+ Explicit knowledge is fact-based and can be easily communicated through words and symbols. Traditional lessons 
learned, processes and procedures, and other information repositories fall under this knowledge type. These are 
generated and shared as the project is ongoing and consolidated as part of project closing. Explicit knowledge, 
however, may need explanation or context to provide value. 


* Tacit knowledge may provide context or explanation to explicit knowledge. It is not easily documented. It includes 
emotions, experience, and ability, which are difficult to communicate in words and symbols but can be learned 
through job shadowing or apprenticeship. 
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Example You can learn a lot about performing an activity by reading the organizations documentation on it and 
being trained by an experienced employee. This is explicit knowledge. However, you will learn tricks and shortcuts by job 
shadowing. Watching an experienced person doing the job will give you tacit knowledge they may not think to tell you if 
they were to train you on the activity. 

On the exam, you may see questions related to establishing an environment that encourages the project team to share 
tacit and explicit knowledge. Or a scenario-based question may have an implicit assumption that knowledge sharing is part 
of executing a project. 

You should also be aware that legal and regulatory requirements and constraints such as nondisclosure agreements 
may limit or impact the gathering and sharing of particular information. 

Example On a project to develop banking software, the team may have access to personal and financial information 
about customers of the bank for which the software is being developed. Team members would obviously not be permitted 
to share this information other than for project work. 


Managing Project Knowledge 

Project artifacts such as the project management plan, project documents (like the lessons learned register and project 
team assignments), and deliverables are inputs to the Manage Project Knowledge process. Techniques for learning and 
sharing knowledge may include workshops, training, and observation. Simply asking, “Walk me through how you would 
do this task,” can encourage understanding. 


Osmotic Communication Informal sharing occurs through the application of interpersonal and team skills, 
including active listening and networking. The agile concept of osmotic communication describes the 


phenomena of communication and knowledge sharing being facilitated and enhanced simply by team 
members being in proximity to one another. 

Example Imagine you work in a cubicle and on the other side of that cubicle works a close colleague. You also have 
a colleague with whom you work closely, but their desk is down the hall. Would you agree that even without trying you 
would know more about the colleague who works right on the other side of your cubicle, just from overhearing their daily 
conversation? That is osmotic communication. 


Lessons Learned 
You will see lessons learned mentioned throughout this book, both as an input to and an output of many processes. As an 
input, they help improve the current project. As an output, they help make the organization better by providing historical 
lessons learned for future projects and project managers. They describe “what was done right, what was done wrong, and 
what would be done differently.” Accurately and thoroughly documenting lessons learned is a professional responsibility, 
and the lessons learned register is a main output of managing project knowledge. Lessons learned should include an 
overview of each situation, what corrective actions were taken, the impacts of actions taken, and the resulting updates to 
project artifacts. 

In the first chapter of this book, we described lessons learned under General PMI-isms. Lessons learned are an 
essential asset to managing a project, as they are taken into account as well as created throughout a project. 


Some useful lessons learned categories that should be captured are: 


Technical Lessons Learned What was right and wrong about how we completed the work? What did we learn that will 
be useful in the future? (Examples include acceptable metrics and variance levels, new processes, improved or revised 
processes for particular results, and the effectiveness of particular acceptance criteria.) 


Project Management Lessons Learned How did we do with work breakdown structure (WBS) creation, risk planning, 
etc.? What did we learn that will be useful in the future? (Examples include recommendations for transitioning project 
results to the business and operations teams, recommended changes to the organizatiorls procurements process, and 
experiences working with particular sellers.) 


Management Lessons Learned What did we learn from communications and leadership efforts that will be useful in the 
future? (Examples include the results of stakeholder analysis and stakeholder engagement efforts.) 
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DEIN Many project managers do not understand the role of lessons learned on projects. Figure 4.5 illustrates 
MAiA their function. 


FIGURE 4.5 Lessons learned on a project 


Monitor and Control Project Work 


Monitor and Control Project Work proceeds from project initiating through clos- 

ing. It involves observing project activities and their results, and comparing the ac- 
tual and forecasted performance to what was planned. This process involves aggre- 
gating the work performance information from the project management processes 

to evaluate and assess how their results are impacting plans and baselines. This pro- 
cess involves monitoring any performance requirements that were included in the 
project management plan. 

Example Scope may be completed but quality may not be acceptable. The 
schedule might be met but at excessive cost. 

This work encourages a holistic view of project performance and enables the 
project manager to take appropriate action to keep the project on track. It also 
includes activities such as analyzing and tracking risks, performing quality control 
activities, assessing possible outcomes across the project using data analysis 


techniques (including alternatives, cost-benefit, earned value, root cause, trend, 
and variance analysis), and reviewing changes and corrective actions made on the 


project to see if they were effective. 


Artifacts of Monitor and Control Project Work 

Ihis effort may result in change requests, work performance reports, and updates to project artifacts. The change requests 
from this and other processes are evaluated and approved, rejected, or deferred in the Perform Integrated Change Control 
process, described later in this chapter. 


Change Requests 
Change requests can have differing focuses, depending on which process they are generated from. Examples of changes are 
additions to project scope requested by the customer, changes to the plan that the team believes would make their work 
more efficient, or even changes to the policies and procedures used on the project. Needed changes are identified as the 
project manager manages the execution of the project and as part of monitoring and controlling when project performance 
is measured against the baseline. 

Not all changes require change requests, but change requests are generated from many processes if they require a 
change to the project management plan or the performance measurement baseline. The three main categories into which 
changes fall are corrective action, preventive action, and defect repair. 
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Corrective Action 
Any action taken to bring expected future project performance in line with the project management plan is a corrective 
action. Since corrective actions deal with actual deviations, there needs to be a realistic performance measurement baseline 
and/or project management plan, including acceptable variances, to determine when a variance has occurred and when 
corrective action is needed. Those who have problems with this in the real world have problems on the exam. 

What do you do on your projects? Do you have predetermined areas to measure, and have you identified an acceptable 
range into which the measurements can fall (control limits) to determine if a project is on schedule and on budget? 

You need to: 

+ Have a realistic project management plan to measure against 

+ Have metrics created during project planning that cover all aspects of the project 

* Consciously focus on identifying areas that need corrective action 

+ Look for problems using observation, active listening, and measurement rather than waiting for them to be brought 

to your attention 
* Know when the project is off track and requires corrective action 
+ Find the root causes of variances 


+ Measure project performance after a corrective action is implemented to evaluate the effectiveness of the 
corrective action 


+ Determine whether there is a need to recommend further corrective action 


* Continue to measure throughout the project 


As you can see, a significant portion of the project manager's time while the project work is being done is spent 
measuring performance and implementing corrective actions as needed. You can expect questions about this 
on the exam. Do not expect all these questions to use the words “corrective action.” 


Preventive Action 
While taking corrective action involves dealing with actual deviations from the performance measurement baseline or 
other metrics, preventive action means dealing with anticipated deviations from the baseline and other metrics. Knowing 
when preventive action is needed requires more experience than calculation because the project manager is evaluating 
trends in the measurement analysis and anticipating that, if they continue, they could lead to deviation from the baseline 
or other metrics. Examples of preventive actions include: 

+ Adjusting the project to prevent the same problem from occurring again later in the project 

* Changing a resource because the resource s last activity nearly failed to meet its acceptance criteria 


+ Arranging for team members to take training in a certain area because there is no one with the necessary skills to back 
up a team member who may unexpectedly get sick 


Proposed changes that would affect the baselines, policies or procedures, charter, contracts, or statements of work 
would likely have to go to the change control board or sponsor for approval, as outlined in the change management plan. 


Defect Repair _ 


Defect repair is another way of saying “rework.” Defect repair may be necessary when a component of the project does not 
meet requirements. As with corrective and preventive actions, defect repair may be reviewed and approved or rejected as 
part of Perform Integrated Change Control. 
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Perform Integrated Change Control 


In the previous section we discussed three main categories of changes request- 
ed on a project. On plan-driven projects, change requests are evaluated and 
accepted, rejected, or deferred in the Perform Integrated Change Control pro- 

cess. A key focus of integrated change control is to look at the impact of each 
change on all the project constraints, the value of which is to reduce the poten- 
tial risk of not meeting project objectives. For example, any scope change needs 
to be assessed for its impact on quality, risk, schedule, cost, resources, and cus- 
tomer satisfaction. It then needs approval through integrated change control 
before it can be implemented, since the scope baseline is part of the perfor- 
mance measurement baseline. 

Integrated change control ensures that as changes are accepted, updates 
and re-planning efforts are completed and project artifacts updated. The 
approved changes are implemented as a function of Direct and Manage 
Project Work, Control Quality, and Control Procurements. 

So, do you need to go through Perform Integrated Change Control to 
make changes to processes or plans that haven’t been finalized? No. When 
developing the project charter, project management plan, and baseline, changes can be made without a formal change 
request. But after the charter and the project management plan have been approved, requested changes need to be evaluated 
in the context of integrated change control. Project document changes like those to lessons learned and the issue log do not 
require change requests if they do not affect the performance measurement baseline or another project management plan 


component. 


IIHR Read exam questions carefully to understand whether a requested change pertains to something that is still in 
ft) Mi, |2§ the process of being finalized or has already been finalized. This will help you determine whether integrated 
change control is required. 


Integrated change control can be a difficult topic on the exam for people who do not work on projects that have 
formal change procedures. It can also be difficult for project managers who simply estimate the cost and/or schedule 
impact of a change and stop there, rather than looking for the impacts of a change on all project constraints. Check your 
understanding of this topic with the following example. 


a Think About It. A stakeholder wants to add scope to the project. You estimate that the change will add two 
oe á weeks to the project duration. What do you do next? 
a 

Try to answer the question. Is your answer to look for ways to save time so the change can be accommodated? Or 
should you get the change approved? How about asking for an extension of time to accommodate the change? 

None of the previous choices are correct. The next thing to do would be to see how the proposed change impacts the 
project cost, quality, risk, resources, and possibly customer satisfaction. Whenever the exam mentions change, keep in 
mind that a change to one project constraint should be evaluated for impacts on all the other constraints. 

Are changes bad? In plan-driven project management and in some industries this may be a controversial question. 
Changes can have negative effects as they may be expensive or disrupt the project. The cost of change tends to increase as 
the project progresses. The function of each process within monitoring and controlling is to control changes. 

In an adaptive environment accommodating many changes is assumed to be an ongoing part of the 
project management process. The definition of scope is emergent rather than defined at the beginning of the ‘alle 
project. But even in change-driven environments change needs to be carefully planned and managed. Focus 

A project manager should work to prevent the root cause of unnecessary changes. The need for many changes in a 
predictive environment may indicate that the project manager did not fully identify stakeholders and uncover their 
requirements, plan for risk, or properly complete other project management actions. 
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To control changes on a plan-driven project, the project manager should: 


* Work to obtain complete and thorough requirements as soon as possible 


* Continue to observe the environment for the possibility of new or missed stakeholders and new or missed 


requirements 


+ Spend enough time on risk management to comprehensively identify the project’s risks 


+ Establish schedule and cost reserves (see the “Risks and Issues” chapter) 


+ Have a process in place to manage change 


+ Follow the change management process 


+ Have a process and templates in place for creating change requests 


* Have clear roles and responsibilities for approving changes 


+ Allow only approved changes to be executed 


* Reevaluate the business case in the project charter if the number of changes becomes excessive 


* Consider terminating a project that has excessive changes and starting a new project with a more complete set 


of requireme 


Changes can 


nts 


be grouped into two broad categories—those that affect the baselines, policies and procedures, the 


charter, contracts, or statements of work, and those that do not. If a change does not affect these artifacts, change 


management policies 
the change typically 


may allow the project manager to approve the change. If the change does affect those key elements, 
needs to go to a change control board and/or sponsor for a decision. Product owners normally make 


these decisions on agi 


Change Control 


e projects. 


Board (CCB) 


Depending on the project manager $ level of authority, their role might be to facilitate decisions about certain changes, 


rather than actually 


make the decisions. Many projects have formally established change control boards responsible for 


reviewing change requests in accordance with the change management plan for the project. The CCB (sometimes referred 


to as the steering committee) approves, defers, or rejects the changes. The results of the decisions are documented in the 


project 5 change log. The board may include the project manager, the customer, experts, the sponsor, functional managers, 


and others. For the exam, assume that plan-driven projects have change control boards. 


Summary Process for Making Changes on Plan-driven Projects 
The exam has many situational questions that deal with how to manage project changes. Here are two examples. 


Question A functional manager wants to make a change to the project. What is the first thing a project manager 


should do? 


Question Someone wants to make a change to the project scope. What is the best thing to do first? 


The answers are the same in either case. A trick for answering questions that ask about the process for making 


Teh changes 
TRADE 


is to know that, at a high-level, the project manager (and team) should follow these steps: 


1. Evaluate the impact Assess the impact of the change on all aspects of the project (for example, this change 
will add three weeks to the project length, require $20,000 additional funding, and have no effect on 
resources). 


2. Identify options This can include cutting other activities, compressing the schedule by crashing or fast 
tracking, or looking at other options. For example, you may be able to decrease the potential effect of the 
change on the project by spending more time decreasing project risk, or by adding another resource to the 
project team. 


3. Get the change request approved internally (through the CCB) 


4. Get customer buy-in (if required) 


Note that changes are always evaluated before any other action is taken. In many cases, evaluation involves using data 


analysis techniques to 


determine the impact of the change on all the project constraints. 
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Next, options to handle the change, such as crashing, fast tracking, re-estimating, and using “what if’ analysis are 
considered and evaluated. (See the “Schedule” chapter for a discussion of crashing, fast tracking, and re-estimating.) 


Think About It. Do you remember the following question from earlier in the chapter? It is an example of the 
: type of question you may see on the exam: 
Ba A stakeholder wants to add scope to the project. You estimate that the change will add two weeks to the project duration. 


What do you do next? 
Notice how the following question is different: 


A change in scope has been determined to have no effect on the project constraints. What is the best thing to do? 


Be careful when reading these questions. Expect the right answer to depend on other details in the question. 
Sometimes evaluation has been done, so the best thing to do is to look for options. Sometimes evaluation and looking for 
options have been done, and the best thing to do is to meet with the sponsor or change control board to ask for approval, 
deferral, or rejection of the change. 

In the second question, evaluation (step 1 in the previous Trick of the Trade™) has been done. The answer would be 
to look for options (step 2), and then meet with the sponsor or change control board (step 3) to discuss the change and its 
lack of impact on the project constraints. After informing the sponsor or change control board, the project manager may 
inform the customer using the process defined in the communications management plan (step 4). 


TRICKS Detailed Process for Making Changes Now that you know the high-level process, let’s look at a more 
(0J: detailed process for making changes: 


1. Prevent the root cause of changes The project manager should not just focus on managing changes; they 
should proactively minimize the need for changes. 


2. Identify the need for a change Changes can come from the project manager, as a result of measuring 
against the performance measurement baseline, from the sponsor, or any other stakeholder. The project 
manager should be actively looking for changes from all sources because discovering a change early will 
decrease the impact of the change. 


3. Evaluate the impact of the change within the project constraints If it is a scope change, how will it affect 
the rest of the scope of the project? If it is a schedule change, how will it affect the rest of the schedule for 
the project? 

4. Create a change request Changes can be made to the product scope, any part of the project management 
plan, contracts, charter, statements of work, policies and procedures, or even the performance measurement 
baseline. The process of making a change should follow the change management plan. 


5. Perform integrated change control How will the change affect all the other project constraints? 


a. Assess the change Does the change fall within the project charter? If not, it should not be a change to 
the project; it may be an entirely different project. If the change is not beneficial to the project, it should 
not be approved. Also note that any change for which a reserve has been created (a previously identified 
risk event) would be accounted for in the project management plan as part of risk management efforts 
and should be handled as part of the Implement Risk Responses process rather than Perform Integrated 
Change Control. The techniques of alternative and cost-benefit analysis are helpful in understanding the 
full impact of a change request. 


b. Identify options Actions to decrease threats or increase opportunities include compressing the 
schedule through crashing or fast tracking, changing how the work is performed, adjusting quality, or 
cutting scope so that the effect of the change will be minimized. Sometimes it may be necessary to accept 
the negative consequences of a change, if the positive impact that would result from the change is more 
valuable to the project. It is a matter of balancing project constraints. 


Example The benefits of adding new scope to the project may outweigh any negative impact. (See the 
“Schedule" chapter for a discussion of the critical path.) 
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c. Get the change approved, rejected, or deferred Again, the project manager may be able to approve 
many changes. But those that affect the project management plan, baselines, charter, etc. would likely 
need to go to a change control board and/or the sponsor. The approved changes are then implemented in 
the Direct and Manage Project Work, Control Quality, and Control Procurements processes. 


d. Update the status of the change in the change log This helps everyone know the status of the change. 
Ifa change is not approved, the reasons it was rejected should be documented. 


e. Adjust the project management plan, project documents, and baselines as necessary Some 
approved changes need to be incorporated into the project baselines. The changes could affect other parts 
of the project management plan or project documents or could affect the way the project manager will 
manage the project. Project documentation must be updated to reflect the changes. This means replanning 
must be done to incorporate the impacts of the change into the new version of the documents and plan 
before the team starts executing the change. For example, if there is a change in scope, the scope baseline 
(the WBS, WBS dictionary, and project scope statement), the project management plan, and the 
requirements traceability matrix should be updated. If that change in scope affects other areas of the 
project, the associated documentation (such as the activity list, resource management plan and other 
resource documentation, schedule, budget, or risk register) also needs to be updated. 


6. Manage stakeholders’ expectations by communicating the change to stakeholders affected by the 
change How often do you remember to do this? You could think of this, in part, as configuration 


management (version control to make sure everyone is working off the same project documentation). 


7. Manage the project to the revised project management plan and other project artifacts 


Agile Change Management 

In agile and hybrid environments, change control is streamlined as there are often many changes to evaluate 
and make decisions about every day. The product owner is part of the team and has much change approval 
authority. They will authorize changes that would not significantly alter the outcome or benefits of the project. 


Note that there are some additional guidelines in relation to agile change management. For example, the 
product owner is typically given a description of business benefits to deliver within a firm budget and timeline. Changes 
that would impact the intended benefits or require more time or budget than tolerances allow still need to be escalated 
outside the project to a steering committee or sponsors for approval. However, everyday decisions and minor changes that 
come with building something new or complex are managed within the team. 


4.4 Exercise 


Test yourself! In your Exercise Notebook, list some common changes on projects and what you would do to 
manage each change. 


Answer 


Because of the wide variety of possible changes that may occur throughout the life of a project, this exercise only 
includes one answer, but it will help you prepare for questions related to change on the exam. 


Common Change How to Handle It 


Customer wants to Make sure you know what the specific scope is and why it is necessary. Make sure all the 

add scope data required in the change request is filled out. Assess the change, including whether risk 
reserves were allocated to accommodate the addition of the scope. Evaluate the impact of 
the change on all constraints. Look for options. Have the change reviewed by the change 
control board if necessary. 
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Close Project or Phase 


In the ECO, domain II, this is known as task 17: “Plan and Manage 
Project/Phase Closure or Transitions.” This process finalizes all ac- 

tivities across tasks and processes to formally close the project, Agile 
phase, and transition of the product to the customer or operations. a 
Plan-driven projects generally have transitions between phases and then a tran- 
sition at the end, while change-driven projects are organized around more fre- 
quently occurring iteration cycles according to a product release plan. In either 
case, similar activities need to be completed to close a project once its phases 
or iterations have been completed. This is an area that is often overlooked or 
done incompletely so think about this section carefully. 


The project manager will work with subject matter experts to analyze the 
data, including all the project artifacts, and complete the final work to close the 
project. Regression analysis will be done to examine the project variables— 
such as the schedule, budget, and risks that occurred—and how they impacted 
the project and its outcomes. The project manager will look at planned versus actual project results, identify variances to 
the plan, along with their impacts, and identify additional lessons learned that can be shared or used in the organization. 


A project manager must get formal acceptance of the project and its deliverables, issue a final report that shows the 
project has been successful, issue the final lessons learned, and index and archive all the project records. Do you understand 
the importance of the items in the Closing column included in Ritas’ Process Chart™? Make sure you are familiar with the 
concepts and actions listed here, and, if you do not currently do these things on your projects, imagine completing these 
activities in the real world. For the exam, be sure to remember that you always close out a project, no matter the circumstances 
under which it stops, is terminated, or is completed! 


Is your project really done when the technical work is done? Not if you don’t close it out! The Close Project or 


Phase process encompasses the actions of closing as outlined in the project management plan. You must 
lM] ensure final requirements have been fulfilled and all product acceptance work is done. This much you could 
have guessed. But there is often work overlooked that is part of the project work, or is known to be project 

work but gets lost in the rush to the next project assigned by the organization. 
Example Outstanding financial work should be facilitated with the organizations finance department (including 
ensuring proper procurement closures). The product is handed off to the customer and customer feedback is solicited. 
Often there is facilitation needed for the customer or operations like training and supervision to ensure operations are 


running as intended. Was this part of the project management plan or is it a separate project? In either case, transitions 
like this are often haphazard at best, but PMI assumes they are well planned as part of the project. 


Finally, appropriate indexing and archiving of records occurs, including final lessons learned. This is another transition 
step that often gets lost at the end of a project but PMI assumes is done properly and completely. 


For the exam, do not forget that there are financial, legal, and administrative efforts involved in closing. Let’s look 
again at the activities presented in Rita’s Process Chart”: 


e Confirm work is done to requirements 

+ Complete final procurement closure 

* Gain final acceptance of the product 

+ Complete financial closure 

+ Hand off completed product 

+ Solicit customer’s feedback about the project 
+ Complete final performance reporting 

+ Index and archive records 


+ Gather final lessons learned, and update the knowledge base 
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Note that the Close Project or Phase process involves getting the final, formal acceptance of the project or phase as a 
whole from the customer, whereas Validate Scope (a monitoring and controlling process) involves getting formal 
acceptance from the customer for interim deliverables. The project needs both processes. 

Does it make sense to you that the Close Project or Phase process is an integration management function? If not, 
think of the example of final performance reporting. Can you see how you would have to report on all project constraints? 
Make sure you are comfortable with project closing and how it applies to proper project management before you take 
the exam. 


A Word on Transitions 

Sometimes transitions to the customer or operations, of products or services built during your project, are included in the 
project as a phase or product increment. But if transition needs are numerous and complex, transitions are a separate 
project in a program. In either case, transitions require that the project manager has a sophisticated understanding of the 
business environment in which the project is taking place. More information on this topic is discussed in the Business 
Environment section of this book. 


A Case Study You Can Use 


Throughout this book we provide numerous examples and analogies to help you think about the material being presented. 
Since your real-world experience is necessary to qualify for and pass the exam, and yet PMI’s framework processes and 
vocabulary do not always align with your experience, a variety of examples and analogies will help stimulate you to “imag- 
ine into reality” what you need to know for the exam. We chose one case study for repeated use throughout this book to 
help you with a consistent application of the concepts discussed. 


Putting It All Together 


Integration management occurs throughout the project. The project manager is constantly pulling all the pieces of the 
project together into a cohesive whole. It is during this process that the project charter and project management plan are 
developed. These two artifacts will guide the project manager § work. The project manager works to manage project chang- 
es and artifacts. During project integration, they also determine which methodologies and practices work best for the proj- 
ect; in other words, they are tailoring to meet the needs of the project. Finally, they ensure that the project or phase is closed 
out properly. 

Do you remember everything involved with project integration? Revisit the Quicktest at the beginning of this chapter 
and make sure you have filled all the gaps you identified when you began the chapter. Go through the chapter again to 
review the areas you are still unsure about. 

Here is the case study that will be presented throughout this book. In each chapter you will learn more about this 
project and answer questions to reinforce your learning. Read the overview here and then complete the following exercise. 


Introducing the Library Case Study 

A project manager has been hired to oversee the creation of a new community library. The scope of the project includes 
construction of a new building, acquisition of furnishings, movement of resources from the old library, and upgrade of a 
software application for patrons using the library. 
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4.5 Exercise 


Review each description of work done by the project manager as part of Integration Management. In your Exercise 
Notebook, write down the integration process and the other project management constraints and categories 
(scope, schedule, cost, quality, communications, risk, stakeholders, and procurement) involved. 


Integration Constraints; other project 
Work of the PM Process(s) management areas involved 


1. Prepared a report for the city council including actual 
spending vs. planned budget, actual schedule vs. plan, 
and risks identified since last monthly report. 


2. Met with the team to discuss estimates for work packages, 
to talk about vacation schedules, and decide on the best 
communication methods for the team to use. 


3. After the foundation of the building was complete, the 
project manager held a team meeting to discuss what 
went well, any quality issues that occurred during the 
work and how those issues were resolved. They also 
talked about any changes to the original design that 
might be needed going forward. 


4. Building foundation adjustments will require a change to 
the architect’s design. These changes require more time 
and cost, these must be approved by the CCB. 


5. The project manager reviews the project every Friday. 
They review the risk register and work performance data 
comparing it to the planned schedule and budget. They 
also read the local paper and read and respond to 
communications from the city council members, mayor, 
and head librarian. 

6. During the grand opening of the library, patrons are 
asked to complete a survey about their thoughts about 
the new facility. 


7. The project manager interviews the mayor to understand 
the community objectives of the new library and the 
key stakeholders. 
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Answer 


Work of the PM 


1. 


Prepared a report for the city council including actual 
spending vs. planned budget, actual schedule vs. plan, 
and risks identified since last monthly report. 


. Met with the team to discuss estimates for work packages, 


to talk about vacation schedules, and decide on the best 
communication methods for the team to use. 


. After the foundation of the building was complete, the 


project manager held a team meeting to discuss what 
went well, any quality issues that occurred during the 
work and how those issues were resolved. They also 
talked about any changes to the original design that 
might be needed going forward. 


Building foundation adjustments will require a change to 


the architect’s design. These changes require more time 
and cost, these must be approved by the CCB. 


. The project manager reviews the project every Friday. 


They review the risk register and work performance data 
comparing it to the planned schedule and budget. They 
also read the local paper and read and respond to 
communications from the city council members, mayor, 
and head librarian. 


During the grand opening of the library, patrons are 
asked to complete a survey about their thoughts about 
the new facility. 


The project manager interviews the mayor to understand 
the community objectives of the new library and the 
key stakeholders. 


Integration 
Process(s) 


Direct and 
Manage 
Project Work 


Develop 
Project 
Management 
Plan 


Manage 
Project 
Knowledge 


Perform 
Integrated 
Change 
Control 
Monitor and 
Control 
Project Work 


Close 
Project or 
Phase 


Develop 
Project 
Charter 


Constraints; other project 
management areas involved 


. 


Cost 

Schedule 

Risk 
Stakeholders 
Communication 
Communication 
Resources 
Schedule 


Scope (design) 
Quality 


Scope 
Schedule 
Cost 


Risk 

Stakeholder 
Communications 
Resources 

Cost 

Schedule 
Stakeholders 
Quality 


Communications 


* Stakeholders 
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Domain I: People 


In this section, which covers 42% of the exam, we will look at the most important aspects of leadership you will need to 
know for the exam. The People domain concerns skills and methods that help you succeed as a project manager and that 
you can use to help others succeed on projects. We will focus on specific tasks listed in the ECO, appropriate to each of 
the following chapters. First, we discuss models related to leadership and communication. Then, we talk about how a good 
leader creates a high-performing team. 


In this section, we cover: 
+ Servant leadership 
+ Emotional intelligence 
e Critical thinking 
+ Communication skills and models 
+ The skillful use of communication technology 
+ Communication methods 
* Motivation models 
* Models of skill mastery 
+ Situational leadership models 
+ Team development models 
+ Conflict management 
+ Leadership responsibilities 
+ Resource management plan 
+ Team charter 
+ Estimating resource requirements 


+ Acquiring resources 


+ Types of team configurations 

* Methods for developing a high-performing team 

* Colocation and virtual teams 

* Individual and team assessments, and project performance appraisals 
* Key performance indicators (KPIs) 


+ Methods for managing the team 
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5 Leadership Skills 


Introduction 


Much of a project manager’s job involves interacting and communicating with people, so it’s important 
for you to have good interpersonal and team skills, including cultural awareness and conflict manage- 
ment. You need to be a leader, motivator, and team builder. You need to be able to establish trust on a 
project, be approachable and influential, and be an effective listener. Your job as project manager is to 
orchestrate and facilitate the success of other experts in their fields. You should also keep in mind going 
into this chapter that while these related Examination Content Outline (ECO) tasks tend to focus on the 
team, these skills apply to working with all stakeholders. 


Without people skills, as a project manager you will lose opportunities to learn about issues 
before they become serious problems. In addition, you need to be willing to address conflict directly 
and in a timely manner. Conflict is inevitable. Always assume you will approach conflict as an 
opportunity to improve the project and relationships with stakeholders. 

So-called “people skills” are so important that the ECO has an entire domain devoted to it. By 
building these skills and effectively working with the team, you can be successful in creating a high- 
performing team. In this chapter we present various models and theories related to learning, motivation, 
and other foundational skills you need to understand and apply as you lead people and projects. 

Many students think this is all intuitive and do not study these sections carefully. They usually 
end up struggling on the exam, or even scoring below target as a result. Pay careful attention to this 
chapter and make sure you understand the concepts presented here. 


Overview of Leadership 


Project managers must be effective leaders and communicators and have the ability to inspire others. 
There is no one right way to lead. You need to know the science of project management and be able to 
utilize different leadership skills and styles based on any given situation throughout the project life 
cycle. This means you should also be able to make expert decisions about what you are doing, even 
when it comes to interacting with and managing people. For example, you may sometimes need to 
coach team members, and at other times simply delegate work. In some cases, you may solicit the 
team’s input or involve the team in making decisions. Whatever the case may be, a project manager 
must be intuitive when leading team members in order to achieve the best possible project perfor- 


mance. 
Leadership involves a sophisticated approach to working with people. We don’t manage people; 
we get work done through others. When leading a project team, consider skills, learning styles, and 
motivations of the team and align project tasks and goals accordingly. This will create more productivity. 
The following chart shows some key differences between management and leadership. 


Management Focus Leadership Focus 


Tasks/things People 
Control Empowerment 
Efficiency Effectiveness 
Doing things right Doing the right things 
Speed Direction 
Practices Principles 
Command Communication 


QUICKTEST 


Leadership 

+ Management vs. 
leadership 

* Critical thinking 

Emotional intelligence 

Servant leadership 

+ Centralized vs. distributed 
management and 
leadership 

+ Flow of communication 

e Communication types 


+ Five Cs of Communication 
+ Communication models 

* Active listening 

+ Gulf of execution 

+ Gulf of evaluation 

+ Communication blockers 
Communication 
technology 

e Communication methods 


+ Communication channels 
Intrinsic vs. extrinsic 


motivation 


Motivation models 
- Theories of X, Y, Z 
- Maslow's Hierarchy of 
Needs 
- McClelland's Theory of 
Needs 
- Herzberg's Two-factor 
Theory of Motivation 
Models of Skill Mastery 
-  Shu-Ha-Ri 
- Dreyfus Model of Adult 
Skill Acquisition 
T-shaped skills 
Situational leadership 
models 
- Situational Leadership 
l® 
- OSCAR 
Team development 
models 
- Tuckman’s Ladder of 
Team Formation 
- Drexler/Sibbet Team 


Performance Model 
Trust 
Negotiation 
Influencing 
Training 
Coaching 
Recognition and rewards 


Conflict management 
Conflict model 
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Is leadership independent of management? Do you practice one and not the other when managing a project? A 
project manager must be able to both manage and lead on projects, with the emphasis on leadership that aids a team and 
other stakeholders in performing at their best. 


5.1 Exercise 


Review the activities below, and determine whether they are mainly leadership or management based. 


1. Human resource management 5. Task assignment 

2. Career planning 6. Team brainstorming 

3. Team time tracking 7. Planning workshops 

4. Team member recognition 8. Negotiating a contract 
Answer 

1. Management 5. Management 

2. Leadership 6. Leadership 

3. Management 7. Leadership 

4. Leadership 8. Management 


Definitions Related to Leadership 


Critical Thinking 

It is the project manager’s responsibility to apply critical thinking skills to effectively manage a project. Like solving a 
Rubiks’ Cube, the project manager should look at a project from all angles, and move the pieces to the right place at the 
right time. Different options will present themselves, emotions will arise, but the project manager thinks strategically 
about how to produce the best end result. Critical thinking involves the following: 


+ Gathering unbiased information 

+ Responding logically, and without bringing more emotion to the situation 
* Resolving issues using analytical skills 

+ Analyzing data to address the issue and choose the right path 

+ Being aware of relationships and related patterns 


+ Identifying when someone is off-base with their reasoning 


Emotional Intelligence 


Emotional intelligence is a well-known set of interpersonal skills associated with having greater leadership success. It 


describes the ability to perceive, evaluate, and control emotions in self and others. For example, an emotionally intelligent 
project manager is able to establish and maintain positive relationships by adjusting communications and anticipating the 
needs of others. They understand how emotion can drive the behavior of others and are able to use this understanding 
when dealing with the issues and concerns of the team. Emotionally intelligent project managers are able to effectively use 
conflict resolution techniques (discussed later in this chapter) because they are perceived as being trustworthy and fair. 
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Emotional intelligence is something that can be learned and developed. It enables a project manager to bring out the 
best in coworkers and team members by making them feel valued and important. Figure 5.1 shows the quadrants of 
emotional intelligence: self-awareness, self-management, social awareness, and relationship management. The core 


competencies are listed in each quadrant. 


Self-awareness Self-management 
* Self-confidence * Self-Control 

With me + Accurate self-assessment + Conscientiousness 
+ Emotional self-awareness + Adaptability 


Social awareness 
+ Empathy 
With others + Organizational awareness 
+ Environmental awareness, 


Motivation, or understanding what drives and inspires people, is often 
described as a fifth component of emotional intelligence. 


FIGURE 5.1 Quadrants of emotional intelligence 


Servant Leadership 


As compared to traditional hierarchical leadership where emphasis is on the authority of the leader, servant leadership 
means the leader shares power and helps enable those they lead to perform their best and to grow. A project manager as 
servant leader, for example, ensures team members can effectively do the work in order to deliver business value. There are 
certain aspects to this kind ofleadership and the focus is always on maximizing team productivity by removing impediments 
and supporting the team’s work. If you see an agile question on the exam that is dealing with leadership, think servant 
leadership. 


There are four primary duties a leader performs in this role of serving the team: 


1. The project manager will make sure team members stay on track and have no unnecessary interruptions, and that 
work unrelated to the project does not get added. 


2. In the daily standup meeting team members name any impediments. These could be compliance- or 
documentation-related issues. The project manager works to remove impediments to keep the team moving 
forward. 

3. The servant leader will continually communicate the project vision so team members have a good understanding 
of the final goal. By doing so, the team can make good decisions to produce the final product. 

4. The servant leader gives the team everything they need to be productive and to stay motivated. The essentials can 
include everything from rewards, compensation, support, or encouragement. 


Centralized vs. Distributed Management and Leadership _ è 
The PMBOK® Guide outlines the differences between centralized and distributed leadership. Centralized teams report to 


one leader, such as the project manager. Distributed management is when the team follows the leadership of several 
individuals. This could be the project manager plus the project management team. Or, the team could be self-organizing 
and no one person is leading the team but rather they share the responsibility. 
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Communication Skills 


Communication is an important part of leadership, and effective communication underpins project success. You will need 
to understand the following aspects of communication for the exam. 


The Flow of Communication 
It’s important to pay attention to how communication flows on a project. 


TRI Project communications occur internally and externally to the core project team—vertically (up and down the 
R CK levels of the organization) and horizontally (between peers). Make sure your planning includes communicating 
TRADE 


in all directions, as shown in figure 5.2. 


i Other project managers, 
Scrum Masters, and team leaders 


Project Team 


Portfolio and program managers 


la 


PMO 


FIGURE 5.2 Flow of communication on a project 


Communication Types 

The first step in effective communication is choosing the best type of communication for each situation. Information can 
be expressed in different ways—formally or informally, written or verbal. You need to decide what approach to use for each 
instance of communication. Make sure you understand the following chart. 


Communication Type When Used 
Formal written Project charter, planning documentation, backlogs, contracts, and 
reports; can be physical and electronic 
Formal verbal Planned meetings and stakeholder briefings; standup meetings and 
retrospectives; can be face-to-face or remote 
Informal written Email, handwritten notes, text messages, instant messaging, social 
media, and websites 


Informal verbal Unscheduled meetings, conversations, and other casual discussions 


108 


FIVE 


5.2 Exercise 
Test yourself! What is the best type of communication in the following situations? 


CeIn ANAwWN = 


U N= Oo 


Situation 

Updating project communications strategies 
Giving presentations to management 

Trying to solve a complex problem 

Updating the product backlog 

Making notes regarding a telephone conversation 
Making changes to a contract 


Scheduling a meeting 


Clarifying a work package 


. Requesting additional resources 

. Trying to discover the root cause of a problem 

. Sending an email to ask for clarification of an issue 
. Holding a milestone party 

. Conducting an online bidder conference 


Answer 


Imagine these as situational questions. Exam questions may have more words, but they will boil down to 
straightforward situations like the ones described in the exercise table. 


Ww N= So LO 


eS N DAUR wWHN S 


. Formal written 


Formal verbal 


. Formal written 


Formal written 
Informal written 
Formal written 


Informal written 


. Formal written 


Formal written 


. Informal verbal 


. Informal written 


. Informal verbal 


. Formal written 


Leadership Skills 


109 


Leadership Skills FIVE 


The Five Cs of Communication 
Certain qualities of written communication enhance the likelihood that communications will be correctly interpreted and 
understood by the recipients. The following qualities should be incorporated by the project manager to ensure that 
messages are effective: 

* Correct grammar and spelling 

e Concise and well-crafted 

* Clear and purposeful 

* Coherent and logical 


* Controlled flow of words and ideas 


Communication Models 

The most basic communication model only ensures that a message has been delivered, but excellent project communication 
requires a more complete approach to communications. A more comprehensive communication model, interactive 
communication, includes three main components: the sender, the receiver, and the confirmation that the message is 
correctly understood. Each message is encoded by the sender and decoded by the receiver. The receiver acknowledges 
receipt of the message, and both the sender and receiver are responsible for confirming that it has been properly interpreted 
by the receiver. 

Factors such as working with different languages and cultures are important, but even the receiver’s perception of the 
message, everyday distractions, or a lack of interest can affect the way the receiver decodes a message. Communication 
models often refer to these types of factors as “noise” because they can interfere with the receiver’s ability to understand 
the message. 

More complicated communication models exist, and different models may be appropriate for different projects or 
components of a single project. Keep the interactive model of communication, as shown in figure 5.3, in mind when 
answering questions on the exam related to communications. 


TRICKS Sending Effective Communication The sender should determine which communication method to use to 
ft) My, [2g send a message, and then encode the message carefully and confirm that it is understood. When encoding the 
Hii] message, the sender needs to be aware of the following communication factors: 


+ Nonverbal A significant portion of in-person communication is nonverbal; this can include gestures, facial 


expressions, and body language. 
* Verbal There are two important aspects of verbal communication: 
/ The words and phrases a sender chooses are essential components of the message, but their meaning can 
be obscured by the accompanying nonverbal factors. 
/ Pitch and tone of voice also help to convey a spoken message. 


To confirm the message is understood, it’s helpful for the sender to ask for feedback using questions such as, “Could 
you rephrase what I’ve said in your own words?” But it’s also up to the receiver to make sure they have received and 
understood the entire message. 

This is especially true in situations involving cross-cultural communication. Senders and receivers of communications 
must be aware of cultural differences, including age, gender, and nationality, and take those factors into account when 


planning, transmitting, and interpreting communications. 


110 


FIVE Leadership Skills 


If a message is not understood, the receiver should acknowledge the message by saying something like, “I’m not sure 
I understand. Can you explain that again?” Like the sender, the receiver needs to encode their response carefully, keeping 
in mind the potential effects of verbal and nonverbal communication, when giving feedback to the sender, as illustrated in 


figure 5.3. 
ye Communication Type oy 


Encoded message sent a Message received and decoded 


Active AZ 
N Listening a . m 
Sie te f i 
how | : 
l f n 4 
(NOISE ))} | Receiver 
Feedback received and decoded Encoded feedback sent 


Communication Type 


FIGURE 5.3 The interactive communication model 


These factors apply to individual interactions as well as to project communications. It’s possible to plan not just the 
types of communications to be used, but also ways for the sender to confirm the receiver has interpreted the message as 
intended. A project manager provides guidance to stakeholders regarding what to communicate and when to communicate 


it. It can be included in planning documents, information radiators, and verbally, and may also include direction on how to 
confirm the understanding of communications. 


Effective Listening So what should a receiver do during in-person communication to accurately decode a 
message and confirm it has been understood? The receiver should pay attention to the sender’s gestures and 
facial expressions, and try to focus on the content of the message without distraction. It ’s also important that 
a receiver practices active listening. Active listening means the receiver confirms they are listening, accurately 
reflects back on the speaker’s remarks, expresses agreement or disagreement, and asks for clarification as necessary. 


A gap in communication can cause something known as the gulf of execution or gulf of evaluation. 


The gulf of execution is related to how closely a feature or product can actually be implemented compared to what the 
user wants. For example, content developers for a zoo website want users to be able to find content related to a search on a 
particular topic, such as “bears.” The content developers want the user to be able to get images, information, blog posts, 
etc., in just one click of the mouse. Because of the massive amount of content their database holds, developers discover that 
users will have to select the type of bear they want more information on. Will it be a polar bear, a black bear, a grizzly bear? 


There is a gap, or gulf, in what the content developers envisioned and what is actually possible. The one-click operation is 
actually more than one click. 
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The gulf of evaluation is a communication gap between the user and the developer. It’s a bit like a game of “telephone.” 
What one person hears is different from what they tell the next person. This reinforces the need to have a good interactive 


model of communication. Figure 5.4 shows what happens when there is a gulf of evaluation on the project. 


How the customer | How the ScrumMaster | How the developers What the customer 
explained it understood it built it really needed 


FIGURE §.4 Gulf of Evaluation 


Communication Blockers 


Like noise in a communication channel, blockers can range from a lack of cultural sensitivity to a failure to provide concise 
messages. Blockers cause miscommunication and can lead to disagreement and confusion. The exam has often included 
one or two questions that ask, “What can get in the way of communication?” or “The following has occurred; what is 


wrong?” The correct answer may include: 


Noisy surroundings + Language challenges 
Distance between those trying to communicate e Culture 


Improper encoding of messages 


Skillful Use of Communication Technology 


Communications can take place in many ways: in person or virtually, over the phone, in writing, through instant messaging 
or text, and via email. These means of communicating are collectively referred to as communications technology. A key 
aspect of planning communications is determining the optimal technology with which to communicate information. Agile 
emphasizes more face-to-face communication, while more formal written communications are necessary when utilizing a 
predictive approach. You can use the following list of questions to determine the appropriate technology based on 


the situation: 
* Would it be better to communicate this information in person or virtually? 


. 


. 


Would it be better to communicate the information through an email or a phone call? 
What technology is the team familiar and comfortable with ? 
How quickly and how often does the information need to be communicated? 


Are there security or confidentiality issues that should be considered when choosing a means of communi- 
cating information? 


e Would a letter sent through the mail get more attention? 


Also consider the complexity of the information that needs to be communicated. Alistair Cockbum 


developed a communication effectiveness model to compare communication methods for their effectiveness A 
and richness, or “temperature.” Figure 5.5, is based on Cockburn $model. Notice two key factors—interactivity Agile 
Focus 


and information density—for several communication methods. This concept is especially important in agile 


environments where complex information is communicated in less formal ways. 
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Interactivity and information density indicate a communication methods’ ability to transfer complex information 
efficiently relative to other methods. In figure 5.5, paper-based communications are the lowest in interactivity and 
information density. Written documents take a long time to create and have to be written so that all stakeholders can 
understand the information, regardless of their expertise. Paper documents are also low in bandwidth, so they do not 
convey emotional tone, feeling, or implicit assumptions. 


Ee 

v 

= Face-to-face 

|| at whiteboard 
a ) Phone 

[ZZZZI7 

Instant 

= messaging 

° 

(8) Video 


conferencin 
Audio 9 
p one 


E-mail 


Interactivity 


Bandwidth/Information Density 


FIGURE 5.5 Information transfer efficiency via technology 


At the other end of the scale, face-to-face communication at an electronic or low-tech whiteboard has the highest 
efficiency. Participants can converse and draw their ideas on the whiteboard. They can use shortcuts for well-understood 
concepts to speed the exchange of information, and they can ask each other questions and get immediate feedback. 
Nonverbal communication such as gestures, facial expressions, and tone of voice are also included. 


Face-to-face communication allows for the most information to be transferred in a given period of time, but it is less 
convenient than other forms of communication. Can you see how this approach would be helpful for the project team, but 


may be impossible with all stakeholders on a project? Think about how you would use this model for your real-world 
projects. 


Communication Methods 

Communication methods can be grouped into the following categories: interactive, push, and pull. In choosing a 
communication method, you should consider whether feedback is needed or if it is enough to simply provide the 
information. Where possible, its’ worth involving stakeholders in the final decision about which methods will meet their 
communication needs. Such decisions will support the stakeholder engagement efforts on the project. 


Interactive communication This method is reciprocal and involves two or more people. One person provides 
information; others receive it and then respond to the information. Examples of interactive communication include 
conversations, phone calls, meetings, instant messaging, and video calls. 


Push communication This method involves a one-way stream of information. The sender provides information to 
the people who need it but does not expect feedback from the recipients. Examples of push communication are status 
reports, emailed updates, blogs, and company memos. 

Pull communication In this method, the sender places the information in a central location. The recipients are then 


responsible for retrieving the information from that location. This method is often used to distribute large documents 
or to provide information to many people. 
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Communication Channels 
Communication channels can be thought of as the number of pathways for communication between parties. When you 
add one more person to the team, does the number of communication channels simply increase by one? No. In fact, there 
is a substantial increase in communication channels. As a result, communication needs can grow rapidly with each 
added stakeholder. 

Communication channels can be calculated using the following formula: 


n(n 1) 


5 n = the number of stakeholders 


Note that n equals the total number of stakeholders. For the exam, be sure to understand the concept, and know how 
to calculate the number of communication channels. 

Let’s practice using this formula with an example. If you have four people on your project and you add one more, how 
many more communication channels do you have? To get the answer you calculate the number of communication channels 
with a team of four and with a team of five, and then subtract to identify the difference. 


Example For a team of four: calculate 4 times 3 (which is n - 1) to get 12, and then divide by 2 to reach the answer, 


which is 6. 
—_ 
FIGURE 5.6 Communication FIGURE 5.7 If you add one more, 
channels for a team of 4. how many more do you have? 
Example For a team of five: calculate 5 times 4 (which is n — 1) to get 20, and then divide by 2 to reach the answer, 


which is 10. The difference between 10 and 6 is 4. Simple! 


TRICKS Did you think the answer was 10? Be carefill of the wording of exam questions. This question did not ask how 
OF THE Meu total channels you have; it asked how many more channels you have. Also notice this: It is surprising 
Heto bow much the number of communication channels rises when you add one person to the mix! The formula is 
simple but not intuitive. Whether or not you have to calculate this formula on the exam, you will have to 


Lunderstand its implications. 


Motivation Models 


How can you maintain the cooperation and motivation of the team if you don’t understand what motivates its members? 
Here, we will look at some motivational theory models. You may need to identify some of these theories on the exam, or 
you may see them as answer choices. 


Intrinsic Versus Extrinsic Motivation 

According to Daniel Pink, extrinsic (external) motivation factors like salary are limited and short-lived motivators. Once a 
person is fairly compensated for their work, it is intrinsic (internal) factors that motivate people. Luckily it is these factors 
you have the most influence over as a project manager. 

Pink put internal motivators into three categories: autonomy, mastery, and purpose. 

+ Autonomy This motivational factor appeals to desires people have to direct their own lives. Examples: Flexible work 
hours, working from home, and being able to influence what projects they are on. While self-managing teams are 
typically associated with agile, good leadership on any project means people on any project team should be able to 
manage their own work. 
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e Mastery This is the desire to improve, excel, learn, and do excellent work. You should be able to assume that the team 
you work with want this and then do what you can to help them be their best. 

e Purpose People also have an intrinsic need for a sense of purpose. Ensuring a cohesive team, a clear project vision, 
and a common understanding will help meet this goal, as well as simply letting people know they’re doing a good job 
and making a difference. 


Theories of X. Y, and Z 
McGregor created the Theory X and Y models of worker motivation and suggested optimal related management styles. 


Maslow added the Theory Z dimension, and Ouchi developed his own version of theory Z. 


TRICKS Theory X Based on the first picture on the right, take a guess as to what Theory X is. 


Answer Managers who accept this theory believe people need to be watched every minute. 
They believe employees are incapable, avoid responsibility, and avoid work whenever possible. 


Theory Y Based on the second picture on the right, take a guess as to what Theory Y is. 


Answer Managers who accept this theory believe people are willing to work without supervision, and 
want to achieve. They believe employees can direct their own efforts. It’s a PMI-ism that this is indeed how 


team members behave, so unless directed otherwise, assume this perspective when responding to exam 
questions. 


Theory Z Maslow proposed the Z dimension as transcendent over goal orientation or even being 
intrinsically motivated. Here motivation is linked to self-realization, values, and a higher calling. 


Ouchi ’s version of Theory Z focuses on the well-being of employees and their families—a job for life 
that takes care of them promotes morale and productivity. 


Maslow’s Hierarchy of Needs 

Maslow’s message is that the highest motivation for most people is to contribute, to grow, and to use their skills. Maslow 
called this “self-actualization.” He created a hierarchy of needs to explain how people are motivated and stated once the 
needs at the bottom of the pyramid are met people move on to the next level. A person cannot ascend to the next level until 
the levels below are fulfilled as shown in figure 5.8. 


fillment, growth, learning 
Accomplishment, respect, attention, appreciation 
Love, affection, approval, friends, association 


Security, stability, freedom from harm 


Need for air, water, food, housing, clothing 


FIGURE 5.8 A representation of Maslow’s hierarchy of needs 
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McClelland’s Theory of Needs (or Acquired Needs Theory) 


This theory states that people are most motivated by one of three needs. A person falling into one need category would be 


managed differently than a person falling into another category. The following table explains the three need categories. 


Primary Need Behavioral Style 


These people should be given projects that are challenging but are reachable. 


achievement They like recognition. 


Affiliation These people work best when cooperating with others. 
They seek approval rather than recognition. 


People whose need for power is socially oriented, rather than personally 
Power oriented, are effective leaders and should be allowed to manage others. 
These people like to organize and influence others. 


Herzberg’s Two-Factor Theory of Motivation 
Herzberg’s theory deals with hygiene factors and motivating agents. 


Hygiene Factors Poor hygiene factors may destroy motivation, but improving them, under most circumstances, will not 
improve motivation. Hygiene factors are not sufficient to motivate people. Examples of hygiene factors include 


the following: 


+ Working conditions + Relationships at work 
e Salary + Security 
e Personallife + Status 


Motivating Agents Assuming hygiene factors are satisfied, people are motivated, energized, and engaged by the work 


itself, including factors such as: 


+ Responsibility + Professional growth 


+ Self-actualization e Recognition 


So, the lesson here is that motivating people is best done by rewarding them and letting them grow. Solving an 
individual or team issue may mean the project manager has to make sure certain basic needs are met within the project. 


Then they can use rewards, recognition, and the roles and responsibilities assigned to individuals and teams. 


Models of Skill Mastery 


Shu-Ha-Ri Model of Skill Mastery 


The shu-ha-ri model comes from martial arts training. It has been adopted by agile practitioners as a way to move through 
three levels of mastering a new skill or process. The three levels are as follows: 


1. Shu: This is where the rules are learned and obeyed—shu means “to keep, protect, or maintain” 


2. Ha: This is when the rules have been mastered through practice—ha means “to detach or break free” 


3. Ri: This is the final stage where the rules become second nature. Practitioners in this stage can also teach and lead 


others—vi means “to go beyond or transcend” 


The leader on an agile team uses this model to develop a high-performing team. 
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Dreyfus Model of Adult Skill Acquisition 


This model proposes that adults learn new skills through 


five different stages: novice, advanced beginner, 
competent, proficient, and expert Like the shu-ha-ri 
model, the idea is that knowledge is gained as the person 


‘Proficient 


Competent 


moves through each phase. As shown in figure 5.9, the Agvanced 
commitment, decision-making skills, and perspective beginner 
also shift as a person moves through the phases. Here, : 
you can see that on the top row the novice starts with a PHiovice 
detached commitment, and that commitment evolves. 
Detached Detached Increased j i 
On the second row, decision-making skills start at commitment commitment commitment Committed Committed 
analytical and move into see as expertise is gained. PREA Holistic view Analytical 
On the bottom row, the perspective changes from none, Follows rules planning of project 
or no opinion, to experienced. The person becomes an Anuutive 
expert in their perspective. a a 
T-Shaped Skills 
One metaphor for assessing skill sets needed for FIGURE 5.9 Dreyfus Model of Skill Mastery 
individual team members is to designate them as 
I-shaped or T-shaped. I-shaped team members specialize 
in one area, while T-shaped team members have a broad range of skills. On hybrid and agile projects where 
the work is done iteratively and incrementally, teams prefer T-shaped people who can help share the workload 
or adapt to the changing needs of the project. T-shaped people help optimize value to the project by file 


reducing bottlenecks. 

Note: While this model in project management is currently associated with hybrid and agile projects, the fact is team 
members on all projects and employees in general are being asked to expand their skill sets so that more team members will 
have a T-shaped skill set. Most important to note here is that people with T-shaped skill sets excel in their core competency. 
Specialists are still needed; hence the agile term generalizing specialists. 


z$ 
o È 


FIGURE 5.10 I- and T-shaped team members 


Sssuraree 
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Situational Leadership Models 


Leadership demands different approaches in different situations, so of course you must tailor your approach to interper- 
sonal communications and leadership depending on the situation. There are many situational leadership models, but here 
we profile the two that are in the PMBOK* Guide: the Situational Leadership 11“ model proposed by Ken Blanchard, and 
Whittleworths and Gilbert s OSCAR model. 


Situational Leadership Il® 

Think of the many people with whom you interact. You probably have an intuitive sense of how to interact with them based 
on a number of things you may know about them: How they take in information, how they react to things in general, and 
factors related to the content of what you are communicating about. Blanchard $ Situational Leadership 11“ model is useful 
in project management as it focuses on two factors: competence and commitment. As you learn a persons competence and 
know how to help them to continuously improve their skills and abilities, and you know their commitment is solid, your 
leadership approach evolves from directing and then coaching to supporting to eventually just delegating. 

e Competence This variable is just what you would expect: a combination of knowledge, skills, and abilities. 


e Commitment This factor is about the confidence and motivation a person has. 


The OSCAR Model 
The OSCAR model is a popular coaching tool that helps leaders define the goals for individual team members. OSCAR 
stands for Outcome, Situation, Choices/Consequences, Actions, and Review. 


* Outcome This is about individual long-term goals. What does that team member want? 

e Situation This is about where the team member is right now in their skill development. 

* Choices/consequences It s here that the team member decides how they will achieve their long-term goals. The 
project manager can help the team member understand the consequences of any choice they make. 

+ Actions In this stage, the team member comes up with a plan of action to achieve those goals. 


e Review Once the team member is on the path, it’s important to review how well those goals are being achieved and 
make course corrections if necessary. 


To learn more about leadership for the exam, be sure to read the free articles “Management and 
Leadership Styles” and “Powers of the Project Manager” on the RMC Resources web page (rmcls.com/ 
rmec-resources). 


5.3 Exercise 
Try this exercise to test yourself on the models we’ve covered so far. Identify which team model belongs to the 
following statements. Note, each model is used more than once. 


. Unconsciously finding an individual path 

. Primary Need: Achievement. “They like recognition” 

. Motivating Agents 

Self-actualization: self-fulfillment, growth, learning 

Hygiene Factors 

Choices/Consequences 

Primary Need: Affiliation—“They seek approval rather than recognition” 
. Obeying the rules 


ee NPH 


Esteem: accomplishment, respect, attention, appreciation 


= 
= 


Outcome 
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Answer 


1. Shu-ha-ri Model of Skill Mastery 

2. McClelland $ Theory of Needs 

3. Herzberg $ Two-Factor Theory of Motivation 
4. Maslows Hierarchy of Needs 

5. Herzberg $ Two-Factor Theory of Motivation 
6. OSCAR Model 

7. McClellands"Theory of Needs 

8. Shu-ha-ri Model of Skill Mastery 

9. Maslows Hierarchy of Needs 
10. OSCAR Model 


Team Development Models 


High-performing teams are made through leadership and the efforts of the team itself. It is about more than the capabilities 
and commitment of the individuals involved. It is very normal for teams to pass through a series of stages or a cycle of 
stages before reaching the level of a high-performance team. The process is very human and not always comfortable, so 
good leadership is needed to foster a safe team environment. Here are two models of team formation and team perfor- 
mance. 


Tuckman’s Ladder Model of Team Formation 

The way the Tuckman model sounds can help you remember it for the exam: “Forming, Storming, Norming, and 
Performing” (and then adjourning). The Tuckman ladder model formally identifies these stages of team formation 
and development: 

¢ Forming People are brought together as a team. 


¢ Storming There are disagreements as people learn to work together. 


e Norming Team members begin to build good working relationships and learn to trust the project manager and 
each other. 


¢ Performing The team becomes efficient and works effectively together. This is the point when the project manager 
can give the most attention to developing individual team members. 


e Adjourning The project ends, and the team is disbanded. 
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New teams may go through each step, while teams that have worked together before may experience a shortened 
version, possibly even skipping some of the early steps. 


“Me" thinking stage. 
Conflicts and disagreements 
result from people looking 
out for their own Interests. 


Getting-to-know-you stage. , 
Lots of questions about 
purpose, team, roles. 


“We" thinking stage. 

Team begins to norm around 
a common purpose and goal 
and show signs of healthy 
team dynamics. 


“Efficient processes" stage. 
Team is working on improving 
their processes so they are 
lean and efficient. 


FIGURE 5.11 Tuckman’s Model of Team Formation 


Drexler/SibbetTeam Performance Model 
Like the Tuckman model, the Drexler/Sibbet Team Performance Model depicts stages (steps) teams go through to form, 
develop, and become high performing. Drexler/Sibbet defines seven stages. 
Steps 1-4 describe where the team is at with the project as they form and develop. In these steps, the team learns “why, 
who, what, and how” of their coming together. 


Steps 5-7 describe what is happening as high performance is attained and sustained. 


Step 1: Orientation, or “Why” The team comes together and learns the purpose of the project. In terms of project 
management meetings and artifacts, think kickoff meeting, business case, project charter, or lean start-up canvas (which 
is a simple yet comprehensive framework for building a clear project vision, proposed solution scope, and success 
criteria). 
Step 2: Trust building, or “Who” This stage is where information is shared and learned about the project team and 
each member s Skills and abilities, as well as whatever other key stakeholder information is available. 
Step 3: Goal clarification, or “What” At this stage the team elaborates on the project information they already have. 
It includes finding out more about stakeholder expectations, project and product requirements, project and stakeholder 
assumptions, and deliverable acceptance criteria. 
Step 4: Commitment, or “How” At this stage the team has formed. It plans for and begins to achieve the projects 
goals. Artifacts can include milestone schedules, release plans, high-level budgets, resources needs, and other high-level 
planning artifacts. 
Step 5: Implementation The high-level plans are decomposed into the greater level of detail for detailed planning, 
and then execution against the plan to produce deliverables. Artifacts to associate with this stage include the projects 
release map, schedule, backlog, or its scope baseline. 
Step 6: High performance At this stage the team has been working together for some time, they work well together, 
have their working agreements ironed out, and have reached a level of high performance. They do not need 
much oversight. 
Step 7: Renewal As changes occur within the project (deliverables, for example) or team (leadership, team members, 
or other stakeholders, for example), the team has an opportunity to look at past performance in perspective to see if 
anything about the way they operate needs to change. The team may revisit previous stages to renew goal clarification, 
commitment, or other ways of working together. 


It is the leader s responsibility to guide stakeholders through organizational change or change on a project. As a leader 


it’s important to have an awareness of how change impacts stakeholders. 
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Other Leadership Concepts 


Trust 
Think of project problems you have recently experienced. Now ask yourself the following questions: “Could these problems 
be caused by a lack of trust? Do team members trust each other? Do they trust the project manager?” The team needs to 
feel that the project manager is working in the best interests of the project, the company, and the team—rather than in the 
best interest of the project manager. Trust is gained or lost from the minute the project manager meets each team member 
for the first time. If the team does not trust the project manager, then they cannot easily be successful. The team will not 
take direction or follow instructions, and the project will suffer. 

An important role of a project manager is to create a psychologically safe work environment where people can ask 
questions and show incomplete versions of their work without being criticized. Providing a team with this level of trust 
increases collaboration and helps improve the project. 


A common method for increasing trust on agile projects is to engage the team in the development of * 


estimates. Activities like Planning Poker®, as described in the Schedule chapter, build trust amongst the team A 
members, the estimate, and the solution. Kad 


Once you have trust, it can be lost if you are not honest and consistent. Assuming you work in a matrix 
organization, how do you get people to cooperate if you do not have the ability to give them a raise or a promotion? Trust, 
as well as a recognition and reward system are the answers. 


e Think About It. Trust also affects, and is affected by, reputation. Do you know what your reputation is? Many of 
(J the people you meet know. Why not ask them about it, so you can deal with any changes you need to make? 


Negotiation 
Negotiation can provide value in developing the team while working to build consensus on project decisions. Including 
the team members in the decision-making process shows that the project manager values and considers their input. 


Influencing 


Influencing is an important aspect of a project managers role that begins with actively listening to differing viewpoints 
expressed by team members. Acknowledging those different perspectives and using communication and persuasion skills 
helps the project manager develop mutual trust and, eventually, agreement within the team. 


Training 
Team members may require training to perform on the project or to enhance their performance. Such training can help 
team members while also decreasing the overall project cost and schedule through increased efficiency. If the training will 
benefit the organization in the long run or can be used on future projects, it may be covered as an organizational cost. 
Otherwise, it is paid for by the project and documented in the resource management plan and included in the project 
budget. 


Coaching 


The goal of coaching is to help team members stay on track, overcome issues, continually improve their skills, and achieve 
their goals. Coaching is done at two levels—with the team and with individual team members. Individual coaching sessions 
should be confidential meetings in a safe environment. During the conversation, it’s important to be frank, yet remain 
positive and respectful. After the meeting, the coach should follow up to make sure there is improvement. 


Recognition and Rewards 


The project manager appraises performance and provides recognition and rewards in response to the work of the team or 


individual team members. To be effective, such rewards should be determined based on the project manager s understanding 
of what is valuable to the team member or group being recognized. In addition to recognizing past accomplishments, 
rewards provide incentive for ongoing achievement and efforts. 
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Conflict Management 
SS  — —  —_L_ SS ——_l lll 


Many situational questions on the exam describe conflicts. Therefore, to be able to pick the best choice from many “right” 
answers, you should understand different conflict resolution techniques and be able to determine which one is best for the 


situation described. 


Think About It. Think about conflict. Is it bad? Should we spend time preventing the root causes of conflict? 
Who should resolve the conflict? Try to answer the questions just posed. Get them right, and you are likely to do 
aa well on this part of the exam. 


The answers are: 

* No, conflict is not inherently bad. 

+ Yes, it is important to identify and deal with the root causes of conflict. 

* Conflict should be resolved by those who are involved, possibly assisted by the project manager. 


+ Although we often think of conflict as a bad thing, it actually presents opportunities for improvement. Many people 
still have outdated beliefs about conflict. For the exam, make sure your understanding reflects the current 


(new) perspective. 


Changing Views of Conflict 


Old New 
Conflict is dysfunctional and caused by personality Conflict is an inevitable consequence of 
differences or a failure of leadership. organizational interactions and the many different 
ways that projects can be accomplished. 
Conflict is to be avoided. Conflict can be beneficial. 
Conflict is resolved by physical separation or the Conflict is resolved through openness, identifying 
intervention of upper management. the causes, and problem-solving by the people 


involved and their immediate managers. 


Conflict is inevitable, in part, because of the following factors. 


+ The nature of projects, which attempt to address the needs and requirements of many stakeholders 
+ The level of emotional intelligence held by team members 


+ The necessity of obtaining resources from functional (resource) managers 


The project manager has a professional responsibility as part of basic project management to attempt to avoid conflicts 
through the following actions: 
+ Keeping the team informed about the following: 


>/ Exactly where the project is headed 
V Project constraints and objectives 
>/ The contents of the project charter 
V All key decisions 

y Changes 


e Clearly assigning work without ambiguity or overlapping responsibilities 
+ Encouraging collaboration and consensus building 
+ Making work assignments interesting and challenging 


+ Following good project management and project planning practices 
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Many people think the main source of conflict on a project is personality differences. They may be surprised to learn 
that this is rarely the case. It only becomes personal if the root cause of the problem is not resolved. On a project, the seven 
sources of conflict in order of frequency are as follows—note that personality is last. 

1. Schedules (unrealistic) 

. Project priorities 


. Resources 


2 

3 

4. Technical opinions 

5. Administrative procedures 
6. Cost 

7. 


. Personality 


Conflict is best resolved by those involved in the conflict. The project manager should generally try to facilitate the 
resolution of problems and conflict as long as they have authority over those in conflict or over the issues in conflict. If not, 
the sponsor or functional managers may be called in to assist. There is one exception. In instances related to professional 
and social responsibility (someone breaking the law, not following policies, or acting unethically), the project manager 
must take the issue to someone higher in the organization. 


Conflict Model 
Based on the work of Thomas and Kilmann, this conflict model offers various conflict resolution techniques to know for 
the exam. Notice that some have more than one title; you should know both. 
e Collaborating (problem-solving) With this technique, the parties openly discuss differences and try to incorporate 
multiple viewpoints to arrive at a consensus. Collaboration leads to a win-win situation. 
¢« Compromising (reconciling) This technique involves finding solutions that bring some degree of satisfaction to 
both parties. This is a lose-lose situation, since no party gets everything. Did you know that compromise is not the best 
choice, but rather second to collaborating? 
¢ Withdrawal (avoidance) With this technique, the parties retreat or postpone a decision on a problem. Dealing with 
problems is a PMI-ism; therefore, withdrawal is not usually the best choice for resolving conflict, though there may be 
situations where it is necessary. 
¢ Smoothing (accommodating) This technique includes making some concessions; it emphasizes agreement rather 
than differences of opinion. It does not result in a permanent or complete resolution of the conflict. 


¢ Forcing (directing or competing) This technique involves pushing one viewpoint at the expense of another. It is a 
win-lose situation. 


Remember to look for collaborating or problem-solving choices as generally the best answers. Forcing is 
usually the worst, but the answer depends on the situation described. There could be situations in which 


withdrawal is the best option. 


Note that we have presented the conflict model definitions as the original sources (Thomas and Kilmann) present 
them. The PMBOK* Guide has a different interpretation on these definitions. On p. 263, the PMBOK* Guide gives a sixth 
definition: Confronting/problem solving, which means treating a conflict as a problem to solve, so “confronting the 
problem.” Notice we used the parenthetical (problem-solving) as associated with collaborating instead because that is 
what Thomas and Kilmann do, as of this writing. It is hard to know if PMI will change this on their PMIstandards+™ 
platform, of it they will include their take in exam questions, so you should understand both of these characterizations. 


I 


fehrcls.com/rm 


Be sure to read about another important conflict management model in the free article “Levels of 
Conflict - Leas Model,” on the RMC Resources web page (rmcls.com/rme-resources). 


RMC RESOURCES 
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5.4 Exercise 


Read each statement made to try to resolve a conflict, and determine which technique is being used. 


Description 
1. “Do it my way!” 
2. “Let’s calm down and get the job done.” 
3. “Let us do a little of what both of you suggest.” 
4. “Let’s deal with this issue next week.” 
5. “Miguel and Kathleen, both of you want this project to cause as little distraction to your departments as 


6. “We have talked about new computers enough. The decision has been made to not get them.” 

7. “Miguel, you say the project should include the purchase of new computers, and Kathleen, you say the 
project can use existing equipment. I suggest we perform the following test on the existing equipment to 
determine if it needs to be replaced.” 

8. “Let’s see what everyone thinks, and try to reach a consensus.” 

9. “Since we cannot decide on the purchase of new computers, we will have to wait until our meeting next 
month.” 

10. “Miguel, what if we get new computers for the design activity on the project and use the existing computers 
for the monitoring functions?” 

Answer 
1. Forcing 6. Forcing 
2. Smoothing 7. Collaborating 
3. Compromising 8. Collaborating 
4. Withdrawal 9. Withdrawal 
5. Smoothing 10. Compromising 


possible. With that in mind, I am sure we can come to an agreement on the purchase of equipment and 
what is best for the project.” 


The next chapter will continue the discussion of working with the team, including acquiring, developing, and 


managing a team. 
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Introduction 


This chapter will cover the technical project management skills related to working with human resourc- 
es on projects that you need to know to pass the exam. These skills are part of the Process Groups 
model for predictive project management, along with related agile project management concepts. As 
you study this chapter, be mindful of the material in the “Leadership Skills” chapter. Technical project 
management skills are not enough to be successful in project management, or on the exam. Working 
with others is so important that 42% of exam questions are based on the People domain in the Exam- 
ination Content Outline (ECO). 

The ECO's Process domain does not have a task dedicated to human resources. Instead, the ECO 
combines interpersonal and team skills with the project management technical skills for leading teams 
and other stakeholders into the fourteen tasks in the People domain. The “Leadership Skills” chapter 
contains information on theories and models related to communication and human psychology, 
which is helpful in applying interpersonal and team skills. 

Be sure to review this chapter’s Quicktest before and after you read the chapter. Make note of the 
gaps in your skills and experience so that you can work to fill your gaps prior to taking the exam. 


Overview of Building and Supporting Performance 


Can we all agree it is amazing to be part of a high-performing team? Yet attaining and maintaining that 
performance level as a team takes effort. There are many things a project manager needs to do to build 
and support high performance within the project team and among all stakeholders, like applying the 
knowledge gained in the “Leadership Skills” chapter to the methods for acquiring resources, develop- 


ing the team, and managing the team that are covered in this chapter. 


The Examination Content Outline and Process Groups Model 

The following shows the fourteen People domain skills, the Process Group model for resources 
management in predictive environments, and of course those PMBOK* Guide domains that most 
directly map to these skills. The People domain of the ECO focuses mostly on the project team, so this 
chapter starts there before covering the Process Groups model for (human) resources. Take a moment 
to glance down the first column here. Notice all tasks are dedicated to building and supporting the 
team. The Process Groups model, while focusing on technical project management activities, relies on 
skills in leadership and in supporting team performance. 


QUICKTEST 


Resource Management 
process 
Responsibility assignment 
matrix (RAM) 
RACI chart 
Organizational breakdown 
structure 
Resource breakdown 
structure (RBS) 
Organizational theory 
Resource management 
plan 

- Human resources 


management plan 
- Recognition 
management plan 
Team charter 
Resource histogram 
Resource leveling 
Types of team 
configuation 
- Dedicated 
- Part-time 
- Partnerships 
- Virtual 
- Pre-assigned 
- Agile 
Negotiating for resources 
Pre-assignment 
Halo effect 
Team building 
Team culture 
Colocation 


Individual and team 
assessments 


Hybrid assessments 


Project performance 
appraisals 


Key performance 
indicators (KPIs) 
Burndown charts 


Burnup charts 


Issue log 
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Domain | Resource Management Domain 2.2 
Task 1 Team 
Manage conflict Plan Resource Management 
“| Planning Domain 2.4 


Task 2 imate Activity Resou Planning 
Lead a team Ee oea 


Domain 2.5 
eo pote Resouces Project work 
Support team performance Develop Team Executing 

Task 4 Domain 2.6 
Empower team members and stakeholders Manage Team Delivery 


Task 5 ~Gentre+Reseurees- — -Monitering— Domain 2.7 
Ensure team members/stakeholders are adequately trained ~&-Gentreting- Measurement 


Task 6 
Build a team 


Task 7 
Address and remove impediments, obstacles, and blockers for the team 


Task 8 
Negotiate project agreements 


Task 9 
Collaborate with stakeholders 


Task 10 
Build shared understanding 


Task 11 
Engage and support virtual teams 


Task 12 
Define team ground rules 


Task 13 
Mentor relevant stakeholders 


Task 14 
Promote performance through emotional intelligence 


oe Think About It. ECO domain I: It’s all about the people! Let’s face it, you need to be doing all these tasks in the 
ô ECO domain, and the enablers serve as examples of the ways they may manifest on a project. As you look at this 
a chart and the ECO, notice how many of the People domain tasks have the word “team” in the name. 


We will talk more about the Process Groups model and agile methods later in this chapter, but for now, notice that we 
have crossed out Control Resources in the middle column of the above table. This is because that process is dedicated to 
material resources like equipment and supplies and not related to managing the team. The concept still applies to predictive 
project management but we discuss it in the Process domain chapter on “Budget and Resources,” since the ECO addresses 
this process with that task. 


TRICKS We have broken the People domain’s fourteen tasks into two groups of seven. This will make them easier for 


(0J you to study. We grouped seven People domain tasks that fit easily into the concept of building performance. 
Hel We then placed the remaining seven tasks into a group that fits nicely with the concept of supporting 

performance. The exercise below supports using this model. Don’t worry about whether our model is perfect. 
You will not be tested on the task numbers or the order of the tasks in the ECO. Ultimately all these tasks are related and 
we include the task numbers in this book only to make them easy for you to find in the ECO. 


TRICKS Do not worry about memorizing ECO tasks and their enablers. What is important here is to make associations 


(0) is) in your mind between these tasks and how they relate to building and supporting performance. Also think 
about the tasks in terms of the information you learned in the “Leadership Skills” chapter and what you are 
learning in this chapter. Having an understanding of the ECO tasks will help you prepare for situational 
questions on the exam better than memorization. 
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6.1 Exercise 
If you have two different colored pens or highlighters available, use them to do the following. You want your 
markings on the ECO to be very visible. 

* Open your downloaded copy of the ECO. If you have not printed it, please do so now. 


+ Then open the ECO to the People domain section. 


1. Look at the following lists, where we have broken the People domain tasks into “build” and 
“support” performance. 


2. In the People domain task list of your ECO, place a large, visible “B” under the task numbers in the ECO 
we have placed in the Build column below. 


3. Then place a large, visible “S” under the task numbers we have placed in the Support column below—in 
a different color, if possible. 


4. Now spend just two minutes going through the tasks and their enablers. Think of them as relating to 
building a team, and supporting a team, respectively. 


5. As you continue to prepare for the exam, take additional opportunities to review these tasks, their 
enablers, and their associations with building and supporting a team. 


Note: We abbreviated some task names while maintaining their meaning. 


Answer 


People Domain Tasks - A Grouping Memory Trick 


Building Performance Supporting Performance 
(2) Lead a team a) Manage conflict 
(4) Empower team members & stakeholders (3) Support team performance 
(5) Ensure adequate training is provided (7) Address & remove impediments for the team 
(6) Build a team (9) Collaborate with stakeholders 
(8) Negotiate project agreements (ID Engage & support virtual teams 
(10) Build shared understanding (13) Mentor relevant stakeholders 
(12) Define team ground rules (14) Promote performance using emotional intelligence 


Leadership Responsibilities 
As the project work is being done, the project manager should know from the project charter what decisions they can make 
and enforce and when they need the approval of someone higher in the organization. It is important to understand how the 
role of the project manager interrelates to the other roles on the project, such as the project sponsor, the functional 
managers, and the team. 


An agile team lead’s roles are defined broadly in terms of being of service to the team. This means doing N 
everything from the ECO People domain tasks. A good leader will focus on making sure the processes needed A ) 
on the project are understood and being followed and that these processes are serving the needs of the A 
team—to provide team training where needed and to remove impediments to project progress. Focus 


If there is a separate project manager role on an agile project, they interface with other appropriate stakeholders like 
the project sponsor and other organizational management. They also help with organizational change management when 


the project will usher in a big organizational change, and they watch for internal and external business environmental 
factors that may affect the project. 
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There are other responsibilities that a project manager role will fill on an agile project, where an agile team lead and a 
project manager role both exist on the same project, like leading a group of several agile teams on the same large and 
complex project. Assume the exam is using the term "agile coach” or “Scrum Master” interchangeably with “project 


manager,” unless information in the question indicates otherwise. 


Here are some important aspects of team leadership to know for the exam: 


* The project manager’s resource management activities are formal and require documentation. 


+ There should be clear roles and responsibilities on the project. For example, who should be assigned to assist the 
project manager, who should take on specific responsibilities at meetings, and who should be completing other work 
not directly related to project activities? Exam topics such as motivation, conflict management, and powers of the 
project manager are more challenging than you might expect. It’s important to know that these concepts need to be 
planned for and managed throughout the project. 


* Projects are planned by the team and coordinated by the project manager. 


* Geographically and culturally diverse teams require additional attention and planning by the project manager. 


e The project manager formally plans team-building activities in advance; these activities are a required part of 


project management. 


* Creating a recognition and reward system is an important resource management function, and such systems are a 
required part of project management. 


* The project manager is responsible for improving the competencies of team members so they are able to perform the 
work on the project most effectively. 


+ The project manager must continually confirm resource availability. 


* The processes of resource management are repeated and updated throughout the project. 


* The project manager is responsible for controlling physical resources on the project; this is not only the responsibility 
of procurement or other departments that may provide physical resources. 


The resource management process takes time and effort to plan. You must do things such as identify all resources 
needed to complete the project (including the required skills of team resources and the required quality and grade of 
material or equipment), define everyone’s roles, create reward systems, provide training and motivation for team members, 
manage the use of physical resources, and track performance. 


Figure 6.1 is a visualization of team leadership at a high level from the Process Groups model perspective, which calls 
the process Resource Management. For this reason, we generally use the term “resource” in place of “team” when talking 


about the specific processes in the 
Process Groups model. The 
model will help you visualize the 
responsibilities and skills for the 
team leadership process, and 
although it applies most directly 
to the Process Groups model, 
many of the concepts make sense 
to know and employ on any 
project. Take a few minutes 
visualizing the process before 
moving on to the Plan Resource 
Management section of this 
chapter. 


t> 


(~ 


-=--> 


Key 
Continuous change control 
is consistent with all 
approaches 


Change prompts a process 
to be reiterated through 
progressive elaboration 

or agile methods 


Changes that cause a 
return to Initiating are rare 


Physical Resources 
(Equipment, supplies etc.) 


Remember, 
it's iterative 


FIGURE 6.1 Resource management process 
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Plan Resources 


Roles and responsibilities and the authority that goes with them are agreed upon in 
planning and documented in the resource management plan. Roles and responsibili- 
ties definition is a critical part of the Plan Resource Management process. Project 
work often includes not just completing work packages, but other responsibilities, 
such as assisting with risk, quality, and project management activities. Team members 
need to know what work packages and activities they are assigned to, when and how 
they are expected to report, what meetings they will be required to attend, and any 
other work they will be asked to do on the project. In a functional or matrix environ- 
ment, the managers of team resources also need to understand when and for how long 
these resources will be needed on the project. 


In short, Plan Resource Management answers the following questions: 


+ How are we going to do all this as a team ? 

+ Who needs to be on the team to accomplish it? 

+ What do I need to do to be a good servant leader on this project? 

Notice the sidebar for this section lists the ECO s People domain, “all tasks.” In Plan Resource Management, you are 
planning to: 

+ Lead the team + Build that team (for high performance) 

+ Empower the team + Build and maintain a shared understanding 

e Get the team the training they need 


To do all this, you need to plan for negotiating project agreements and help the team define their own ground rules. 

Now, that covers the “build performance” concepts discussed earlier in the first exercise in this chapter. What about 
the “supporting performance” work for the project, as the team gets to building the product and things get more challenging? 
Yes—you must support performance, too, by: 


+ Managing conflict + Mentoring stakeholders 
+ Removing impediments + Using emotional intelligence to 
* Collaborating with (other) stakeholders promote performance 


+ Engaging and supporting a virtual team, if needed 


Your plan must also answer questions such as: 

+ What resources are required? 

+ What quantity of each type of resource is needed to complete the project work? 

+ When and for how long will each resource be needed? 

+ Is there a limited time during which each resource will be available for the project? 

+ How will the resources be acquired? 

+ Are all resources available internally, or will the procurement department need to be involved? 
+ What will be the cost of these resources? 


+ How will resources be managed throughout the project? 


On agile projects, its more common for the same team members to remain on the project from 
beginning to end. Teams remain stable and projects are brought to the team. Team members are often 
“T-shaped” generalizing specialists—generalists in many things, expert of a few. Many agile team members + 


share responsibilities for several roles; for example, testing as well as building the product. 
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Artifacts Needed for Planning Resource Management 
Before you can define roles, responsibilities, reporting structure, and so forth, you'll need to consider many factors often 
already documented in the project management plan: 

¢ Project life cycle and processes This should be determined for you to do resource planning. 

¢ Work approaches How work will be done. 

e Communication needs of stakeholders One of the most early documented factors. 

¢ Stakeholder register This lists the individuals and groups who are project stakeholders. It includes analysis of 
factors such as each stakeholder s power and interest related to the project. 

¢ Stakeholder engagement plan This includes the approach for team and other stakeholder involvement, for 
engaging them in the planning, decision-making, and project work. 

e Scope baseline This includes descriptions of project deliverables and helps the project manager determine resources 
needed to create them. 

* Quality management plan This includes agreed-upon levels of quality and grade of physical resources needed to 
satisfy project requirements. These decisions will impact the teams’ options in terms of how and where they will 
obtain these resources. 

«Procurement management plan This plan describes how the project manager should interact with the 
procurement department to facilitate obtaining needed human or physical resources. 


Project Documents Several project documents can be used to plan resources, for example, requirements documentation, 
the project schedule, and the risk and stakeholder registers. These documents provide key information for what type of 
resources will be needed to complete project work, the timeline for them, and how many resources will be required to get 
particular work done. 


Enterprise Environmental Factors Before you develop a resource management plan, understand what enterprise 
environmental factors may come into play. These are the company culture and existing systems the project will have to deal 
with or can make use of. Consider the following: 


+ What internal organizations will be involved in the project? 

+ Are there hidden agendas? 

+ Is there anyone who does not want the project’? 

+ Are assigned and potential team members colocated or based in different offices and/or countries? 
+ What is the availability of contract help? 

+ What is the availability of training for project team members? 


Organizational Process Assets These can increase the efficiency of creating the resource management plan, and the 
effectiveness of the resulting plan. Consider assets such as: 

+ A resource management plan template (typically describes standard resource needs and responsibilities) 

+ Existing policies and procedures for resource management 

e Historical information, such as lessons learned from similar projects 


Methods for Planning Resource Management 

There are many tools and techniques that can be used to document and communicate roles and responsibilities of 
management, team members, and other stakeholders. The PMBOK* Guide lists these as artifacts, but of course you also 
need to know how to use the data gathering and analysis methods (or tools) for creating these artifacts. Examples include: 


+ Responsibility assignment matrix (RAM) e Organizational breakdown structure 
+ RACI chart * Resource breakdown structure (RBS) 
+ The work breakdown structure (WBS) * Organizational theory 


For the exam, you will not be asked whether any of these are methods or artifacts. Rather, you will need to know what 
each tool displays and is used for so you can answer situational questions that include them. 


ISO 


SIX Build and Support Team Performance 


Ri ibili signme: ix (RAM, . 
Ibis chart cross-references team members with the activities or work packages they are to accomplish. Figure 6.2 is an 
example of a RAM. Note it does not show time, or when people will do their jobs. 


Team Member 


Activity Karla Patrick Muhammad Trisha 
A P S Key 
B S P P = Primary 
responsibility 
S = Secondary 
FIGURE 6.2 Responsibility asstignment matrix responsibility 


RACI Chart (Responsible, Accountable, Consult, and Inform) _ — 

This chart is a type of RAM that defines role assignments more clearly than the example shown in figure 6.2. Instead of the 
P and S shown in the figure, the letters R for Responsible, A for Accountable, C for Consult, and I for Inform are used. Note 
that multiple resources may be responsible, informed, or consulted, but only one person is held accountable. 


Organizational Breakdown Structure Project 


This tool (figure 6.3) is used to assign responsibilities to | 
divisions or departments within the organization, such as | ZZL 


rketi . i ir j = Marketing — m Í 
marketing or IT. In a matrix environment, the project manager department aopa nsr Ete. 


will interface with the managers of each department involved 
in the project to coordinate availability and scheduling of 


: ; L WBS347 WBS 2.4.6 
human and physical resources for the project. Customer needs survey Cloud transition plan 
Resource Breakdown Structure (RBS) = WES745 WBS 1.1.2 | 
A WBS is typically referenced to create this chart. Similar in pone Fala ed} 
format, the RBS breaks the work down by type of resource TERY 


needed, as shown in figure 6.4. Usability test plans 


FIGURE 6.3 Organizational breakdown structure 


FIGURE 6.4 Resource breakdown structure 


Work Breakdown Structure (WBS) Aih 
You’ve already seen that we refer to a WBS to create an RBS. The WBS, which we discuss in the “Scope” chapter, is a great 


tool to ensure each work package has an “owner”—a team member responsible for that work. 
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Organizational Theory 


Organizational theory is a method to study organizations to identify how they solve problems and how they maximize 
efficiency and productivity and meet the expectations of stakeholders. This analysis helps the organization develop 
effective resource management policies and procedures for the acquisition, management, and evaluation of 

human and physical resources. Adopting practices such as Lean, Kaizen, just in time (JIT), or Six Sigma 

influences how projects will handle the management of physical resources. These practices are covered in the 
“Quality of Deliverables and Products” chapter and the “Agile Methodologies” chapter. 


Artifacts of Plan Resource Management 
The Plan Resource Management process results in a resource management plan, a team charter (including ground rules), 
and updates to the project management plan and project documents such as the assumption log and risk register. 


Resource Management Plan 

If you manage small projects, think about what the resource management effort would involve on a large predictive project 
that has hundreds of assigned resources. Would it take more work than you are doing now to manage the resources on your 
project? 


Components of a resource management plan include the following: 

¢ Human Resources (Team) Management Plan 
>/ Team requirements (who, when, how many, what skills, what level of expertise, duration) 
y Roles and responsibilities 
y Project organizational charts 
y Process for acquiring human resources (internal or procurement) 
y Training, team development, and recognition (goals, what, when) 
y Project team management (team charter, ground rules, engagement, communications) 
y Compliance (How will the project comply with any rules related to human resources?) 
y Safety (policies to protect the resources) 
y Release of human resources 

¢ Recognition Plan 

Recognizing individual and team accomplishments is one of the most effective ways to motivate people. It should 
include when and how resources will be recognized, and what actions or achievements will be rewarded. 

Everyone likes to feel appreciated. A good start to planning how to use recognition and rewards is to make a 
conscious effort to personally acknowledge the efforts of team members. A smile and a “thank you” are often more 
meaningful than you might think. To make the rewards more personal, you can ask team members and stakeholders 
what they want to get out of the project, on a professional and personal level. They might respond with such things as, 
“I want to learn more about XYZ,” “I want to decrease the time I am allocated to this project,” “I want to make sure I 
leave work on time on Tuesday nights because I have a family obligation,” or “I want to be assigned a certain piece of 
the project work.” 

As the project progresses, the plan may be iterated as new team members are added, and as the project manager 


becomes more familiar with the team and what motivates them. Recognizing and rewarding might include doing the 
following on an ongoing basis, while project work is being done: 


y Saying “thank you” more often 
y Awarding prizes for performance 


y Recommending team members for raises or choice of work assignments (which may not officially be part of 
the team members’ performance reviews) 


y Sending notes about great performance to team members’ managers 
y Planning milestone parties or other celebrations 
y Adjusting the project to assign people to activities they want to work on 


y Assigning a new team member to a non-critical-path activity so they can learn in that area 
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The list could go on and on, but ask yourself, “Do I do any of these things? Do I do them systematically?” This requires 
planning in advance and then iterating that plan as the project progresses. 


Team Charter 

This document is a working agreement developed by the members of the project team. The team charter describes the 
approach the team will take regarding communications, decision-making, and conflict resolution, as well as ground rules 
for team meetings. The team charter is a project document and can be referenced at any time during the project. 

Setting ground rules can help eliminate conflicts or problems with the team during the project because everyone 
knows what is expected of them. And if team members have input on the creation of the ground rules, they’re more likely 
to follow them. Ground rules can be especially important when the team is managed virtually. 

The ground rules may include items such as the following: 

+ How a team member should resolve a conflict with another team member 

+ When a team member should notify the project manager that they are having difficulty with an activity 

+ Rules for meetings 

+ Who is authorized to give direction to contractors 

+ How the team will decide work assignments 

+ When and how to provide status updates to the project manager 

e Methods for coordinating and approving changes to team members’ calendars, both in normal and 

emergency situations 


On predictive projects with unchanging requirements or technology, it is appropriate to plan thoroughly and then 
execute. But on agile projects key elements are likely to change so a high degree of planning may be inappropriate. Therefore, 
it’s important for teams to have the processes (e.g., prioritization, demos, retrospectives) in place to allow for effective and 
efficient adjustments during the project. 


Estimate Resource Requirements 


At this point in resource planning the project manager and the team have a plan in 
place for how resource needs will be coordinated. In predictive project management, 
the project manager now must estimate the type and quantity of all resources needed 
to complete project work at the work package and activity level. 

The resource management plan includes documentation on estimating methods 
that may be used. Other artifacts containing the needed information are on the 
following list. Remember that planning is iterative, so the team may use all these 
artifacts together to plan requirements while at the same time refining scope, 
schedule, and cost planning. These are artifacts of tasks in the Process domain: 


° Scope baseline and activity list (see “Schedule” chapter). 


e Work breakdown structure (WBS) Work package estimates are created 
while planning scope. 


e Network diagram Activities are shown in the network diagram (see the 
“Schedule” chapter). 


e Activity attributes These provide specific information about each activity, like the type and quantity of resources 
expected to be needed to complete those activities. 


e Cost estimates These provide resource estimating constraints since resource costs must fall within the cost baseline. 


e Resource calendars Also related to Schedule Management, these identify organizational work hours and company 
holidays, thus helping to show the availability of potential resources. 

e Organizational process assets Established policies and procedures are always considered when arranging for staff 
and needed equipment. 
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Methods for Estimating Resource Requirements 

Estimating techniques are discussed in the “Schedule” and “Budget and Resources” chapters. Several of those techniques, 
such as analogous estimating, may also be used to estimate activity resources. Here are some other methods to know for 
the exam about estimating resources. 


Resource Histograms and Resource Leveling 
Resource histograms and resource leveling are methods for the “what if’ analysis to refine estimates and ensure resources 
are available when they are needed, and not when they are not needed. 


Resource Histograms This tool provides a method for visualizing resource requirements and comparing required 
resources to their availability to better enable estimating. Figure 6.5 shows a resource histogram (a bar chart) illustrating 
the number of resources needed per time period. It allows a project manager to easily see where there is a spike in the need 
for resources. If the people are not available when they are needed, the project manager must evaluate available options, 
which may include: 

+ Negotiating with another department to provide resources 

* Procuring the resources from an external source 


+ Adjusting the schedule to do the work when the resources are available 
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Dedicated to Project 


Project Time Period 


FIGURE 6.5 Resource histogram 


Resource Leveling This technique maybe used to change a project to minimize the peaks and valleys of resource usage 
(level the resources). A resource histogram can also be used to help perform that task. 


Artifacts of Estimate Resource Requirements 

After estimating resource requirements the project manager and the team will have determined requirements for project 
activities, including cost, quantity, and availability of team members. Remember from figure 6.4, the requirements may be 
documented in a resource breakdown structure (RBS), so this artifact will have undergone another iteration. 
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6.2 Exercise 
In the below table, identify which activities are involved in Estimate Activity Resources. Here or in your Exercise 
Notebook write “ Y” if the described action is part of the Estimate Activity Resources process. If it’s not, write “N.” 


Action: Is it part of Estimate Activity Resources? (Y/N) 


1. 


2: e 100 cS ON rR a a 


Review project management plan. 

Review scope baseline. 

Review resource availability. 

Review cost estimates. 

Get one time estimate per activity. 

Complete an analysis of the reserves needed on the project. 

Create a company calendar identifying working and nonworking days. 
Create milestones. 


Review the WBS, activity list, and activity attributes. 


. Review the risk register and assumption log. 

. Identify potentially available resources and their skill levels. 

. Review historical information about the use of resources on similar projects. 
. Review organizational policies on resource use. 

. See how leads and lags affect the time estimate. 

. Solicit expert judgment on what resources are needed and available. 

. Create bottom-up, analogous, or parametric estimates. 


. Analyze alternative equipment or methods to use in completing the work and approaches to better 


utilize resources. 


. Show network dependencies per activity. 


. Identify areas of the project that cannot be completed internally or would otherwise be more efficiently 


achieved through outsourcing. This information will be shared with the procurement department. 


. Crash the project. 


. Break the activity down further if the activity is too complex to estimate resources 


(bottom-up estimating). 


. Quantify resource requirements by activity. 


. Create a hierarchical image that organizes the planned resources by their category and type (a resource 


breakdown structure). 


. Fast track the project. 
. Develop the schedule. 
. Develop a plan as to what types of resources will be used. 


. Update project documents. 
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Answer 


Action: Is it part of Estimate Activity Resources? (Y/N) 


LY 7.N 13. Y 19, Y 25. N 
2Y 8. N 14. N 20. N 26. Y 
3.Y 9.Y 15. Y 21.Y 27.Y 
4.Y 10. Y 16. Y 22. Y 
5.N my iY 23. Y 
6. N 12.Y 18. N 24. N 


Acquire (and Release) Resources 


The sidebar tells you that once again we have mapped Acquire Resources from the 
Process Groups model to all tasks in the People domain. In predictive environments 
this process describes how people join the project at the times needed to complete 
their work. While this process is called “Acquire Resources,” releasing people from the 
project happens throughout it as they finish their work. As the project manager on- 
boards new team members, works with them, and releases them from the project the 
project manager is indeed combining all tasks associated with the People domain. 

Notice that in the Process Groups model this is an executing process. It involves 
following the resource management plan to secure people as they are needed. Ihe 
resource requirements documentation tells the project manager what types of team 
members are needed, and the resource management plan describes from where team 
members will come (from within the organization or as contractors, for example). 


The schedule and cost baselines provide essential information regarding when 
different team members will be required and the amount of funds budgeted to pay for them. 


To understand why this is an executing process, think of a large project that may last a very long time, require a 
hundred or more people and lots of physical resources. 


+ A planning team is acquired early in the project to help the project manager. 
+ Many of the people needed for the work may not be needed until long after the project starts. 


+ The final team list might include contractors, sellers, and people who will work on the project far into the future and 
may not even be employed by the company until needed. 


e Over time people and physical resources will enter and leave the project as their associated work is needed. 


The project manager will also use the resource requirements documentation as a reference in acquiring physical 
resources. Often this involves working with the procurement or inventory management department. 


As mentioned earlier when resource calendars and resource leveling was discussed, resource availability is coordinated 
to ensure that the right resources will be available when they are required. 


To review, acquiring project resources includes all the following: 

+ Knowing which resources are preassigned to the project and confirming their availability 

+ Negotiating for the best possible resources 

+ Hiring new employees 

+ Hiring resources through the contracting process from outside the performing organization (outsourcing) 
+ Using JIT, Lean, or other methods as required by the organization 


+ Managing the risk of resources becoming unavailable av. b 
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Agile Teams 
An agile environment looks a little different from the predictive environment described in the Acquire 


Resources process. Here is how it typically works. Agile teams: M e 
ocus 


« Are stable They work together over time, and projects are brought to the team, not the other way 
around. This practice takes advantage of time and effort taken to bring a team to the level of high performance. Team 
members are on the project together from start to finish, so the scenario describing acquiring and releasing resources 
throughout the project does not apply. 
¢ Are relatively small They include about 8-12 people. Although this range may vary slightly depending on what 
source you consult, it is a good rule of thumb to describe team size. Agile projects are typically smaller than their plan- 
driven counterparts, and although they can be very large, the exam does not test agile on a large scale. 


¢ Have all needed team members An agile team typically includes the project manager (for the exam, a role akin to 
an agile coach or Scrum Master), product owner, product developers, and testers. 


Hybri ironments 
On a hybrid project it is not unusual to plan the overall project using predictive methods and then build the product 


features using iterative and incremental (agile) methods. Variations on these approaches depend on the project and the 
business environment. 


Types of Team Configurations 
The makeup of the final project team can take one or a combination the following: 


Dedicated Teams Most of the team members work full-time and exclusively on the project. Team members can dedicate 
most of their energy to the project and often report directly to the project manager. In a predictive environment, these are 
most common in projectized organizations, but can also be found in matrix organizations. They’re least likely to exist in 
functional organizations. 


Part-time Team Members Team members and the project manager spend a portion of their time working on the project 
while also working on other projects and/or their operations-related work responsibilities. Part-time teams are most often 
seen in functional and matrix organizations. 


Partnerships In cases where several organizations undertake a project, the teams are likely to consist of people from each 
of the participating organizations, plus the project manager from the organization taking the lead on the project. Such 
teams may offer advantages, such as cost savings, but team management and communication can be more difficult. 


Virtual Teams Geographic distance necessitates the use of virtual teams, and technology can help with virtual team 
communication (see the “Communications” chapter). Advantages of virtual teams are that the project manager can 
negotiate for the best resources needed without regard to location and, increasingly, people see working virtually as a 
personal value added. 


Pre-assigned Team Members As noted earlier, sometimes resources are assigned before the project begins. Preassigned 
resources are listed in the project charter. 


Agile Team Structures Remember that dedicated teams are important on rapidly changing agile projects. ) 
In these environments, more information is communicated face-to-face and tacit knowledge is more valuable. P > 
Agile organizations also try to avoid virtual teams where possible. Technology helps agile teams work k 
virtually, but face-to-face communication is always preferred. 
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For the exam, be aware how the type of team described in a situational question could impact the project 
manager $ work. For example, the project manager will have more rapport with a dedicated team. With a part- 
time team, the project manager will likely have to negotiate with functional managers and organizational 
leadership to acquire and retain team members. With a partnership or virtual team, coordination among the 


various organizations or locations might require increased risk management work, more effort to coordinate 
communication, and so on. 


Negotiating for Resources We mainly reference negotiation in this book in two contexts: procurement and onboarding 
internal resources. If people need to be hired or contracted, the project manager may need to work with the human resource 
or procurement departments. This section covers negotiating for internal resources, which are always constrained. To 
negotiate for team members from within the organization, the project manager should do the following with each 
resource manager: 

* Know the needs of the project. 

* Know the projects priority in the organizations initiatives. 

+ Be able to express how the resource manager will benefit from assisting the project manager. 


e Understand that each resource manager has their own priorities and supporting the project may not be of direct 
benefit to them. 


* Do not ask for the best resources if the project does not need them. 


+ Be able to prove, using artifacts like the network diagram and project schedule, why the project requires the stated 
quantity and quality of resources. 


+ Try to discover what the resource manager may need. 


Be open to finding creative ways to help the resource manager meet their own resource needs. 


Build relationships in order to call on the expertise of the resource manager later in the project as necessary. 


e Work with the resource manager to deal with situations as they arise. 


Methods for Acquiring Resources 
There are several methods for acquiring resources. Here are the main ones to know for the exam. 


e Multicriteria decision analysis 
+ Interpersonal and team skills 


+ Pre-assignment 
+ Virtual teams 


The project manager may establish a set of criteria to help choose potential team members. Factors that address the 
needs of the project, such as availability, cost, experience, location, and/or a required skill set, are weighted by importance, 
and the project manager evaluates potential team members based on the selected criteria. 


Pre-assignment 


Sometimes resources are assigned before the project begins. Preassigned resources are documented in the project charter. 
Beware, however, of the halo effect. 


Halo Effect Project managers (and managers in general) have a tendency to rate team members high or low on all criteria 
due to the impression of a high or low rating on one specific criterion. 

Example A project manager might say to a team member who is a great programmer: ”We are making you a leader 
of a programming team for the project and think you will be great at that.” Since a person who is a great programmer may 
in fact, be neither qualified nor want to be a team leader, such assumptions may have negative impacts on the project 
schedule, cost, quality, and team morale. 
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Artifacts of Acquire Resources 

Outputs from the Acquire Resources process are: 
+ Resource assignments 
+ Resource calendars showing the planned utilization and availability of resources 
+ Project management plan updates: 


V Resource management plan 
>/ Cost baseline 


+ Project document updates: 


m/ Lessons learned, risk register, resource requirements 


>/ Resource breakdown structure (RBS), stakeholder register, project schedule 


Think About It. Take a look at the list of outputs from Aquire Resources again. For exam questions, you will 
need to understand these intuitively, but to also quickly know, “Where am I in the project management process?” 

Example If a scenario describes adjusting a plan and uses future tense (like “adjusting the plan that will be 
used...”) without mentioning integrated change control, is it an agile project? If it is not an agile project, then 
you are probably in planning and should pick an answer related to planning. 


Here are things to remember about what you have from (outputs of) the Acquire Resources process: 

+ If decisions made in this process require changes to approved management plans or project documents, change 
requests are submitted to integrated change control. Affected documents and plans may include any of the plans or 
baselines within the project management plan. 

+ The resource management plan may be changed based on the project experience to date. For example, the plan to 
acquire future team members may need to be adjusted if it doesn’t work as expected. 

+ The project schedule may need to be adjusted to accommodate the availability of people with specific expertise 
needed by the project. The cost baseline may be impacted if hourly rates are different from what was estimated. 

+ Project documents need to be updated or changed, with new team members added or information changed in the 
stakeholder register. The resource breakdown structure is iterated to include specific information about people that 
have been committed to the project. 

+ Newly identified risks related to human resources are added to the risk register, reviewed, and analyzed. For example, 
a person with unique qualifications could be called away during the project. 

+ Resource requirements, including the type, quantity, and skill level may change. 

+ There are usually lessons learned to be captured, integrated into the project for future work, and shared with 
the organization. 


Develop Team 


Models for human development and motivation were discussed in the previous, 
“Leadership Skills” chapter. Again here, all the People domain skills are also needed. 
The Develop Team process involves the work to lead, empower, and motivate the 
team to achieve high performance levels in meeting project objectives. 

Apian for making all this happen should be included in the resource management 
plan. And the project manager will need to make use of lessons learned earlier in the 
project and on other, similar projects. Before continuing, go back to the “Leadership 
Skills” chapter and review the models there. They are useful for distilling complicated 
human interaction into understandable common experiences. 


159 


Build and Support Team Performance SIX 


Methods for the Developing Team Process 
Here are the methods for developing a team: 


* Colocation © Training 
+ Virtual teams © Individual and team assessments 
+ Interpersonal and team skills y Individual assessments 
V Team building y Team assessments 
y Conflict management y Hybrid assessments 
V Influencing y Project performance appraisals 
>/ Motivation y Key performance indicators (KPIs) 
y Negotiation ® Communications technology for virtual teams 


+ Recognition and rewards 


Team Building 


Team building can play a major role in team development—helping to form the project team into a cohesive group working 
for the best interests of the project and enhancing project performance. Strong teams will result when you know the 
following key points: 


. 


. 


It is the project manager's job to guide, manage, and improve the interactions of team members. 

The project manager should work to improve trust and cohesiveness among the team members. 

The project manager should make sure that the project vision is clear, and continuously communicate that vision. 
The project manager needs to ensure that roles and responsibilities are clearly defined. 

The project manager should incorporate team-building activities into project activities. 

Team building requires a concerted effort and continued attention throughout the life of the project. 


Team building should start early in the life of the project. 


Project managers who feel they do not have time for team building typically are not using project management best 
practices on their projects. Practices such as properly planning a project and managing risks and quality save significant 
amounts of time on a project, freeing up the project manager to do other important things, like team-building activities. 
When you take the exam, assume the project manager featured in the questions has a team-building plan appropriate to the 
size and characteristics of the team. 


Team-building activities can include the following: 


. 


Involving team members in planning the project, including creating the WBS or backlog as a group 


Taking classes together 


Retrospectives by the team to evaluate and improve their processes and interactions 


Collaborative problem-solving 


Milestone parties 
Holiday and birthday celebrations 


Skills assessments and development 


Team Culture 

The project manager plays an important role in developing a positive team culture. While human beings are complex and 
will create their own habits and relationships, the project manager can lead by example to create a positive work 
environment. Here are some of the ways this can be done: 


. 


. 


. 


Transparency + Support 
Integrity * Courage 
Respect e Celebrating successes 


Positive interactions 
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The more a project manager works to display the actions they want to see from team members, the more successful 
the leader, the team members, and the project will be. All these traits also lend to a safe and open environment where 
people feel comfortable to voice opinions, bring up issues, and solve any problems as a cohesive team. 


Colocation 

A project manager might try to arrange for the entire team in each city to have offices together in one place or one room. 
This is called colocation, and it helps improve communication, decreases the impact of conflict (since all parties are right 
there), and improves project identity for the project team and for management in a matrix organization. The project 
charter, work breakdown structure (WBS), network diagram, and schedule may be posted on the walls to keep everyone 
focused on the work of the project. Adaptive development approaches encourage colocation. 


Virtual Teams 

Not all teams meet face-to-face. Virtual teams have to rely on other forms of communication to work together. Although 
virtual teams can be more challenging to manage because of communication issues and differences in schedules, languages, 
and/or culture, they offer the opportunity to benefit from the expertise of team members who are in distant locations or 
who are otherwise unavailable to participate with the team onsite. 

The challenge for virtual teams is finding ways to create “virtual colocation”—in other words, replicate the benefits of 
face-to-face collaboration, osmotic communication, tacit knowledge, and improved relationships that come from working 
near each other. Fortunately, the same tools making virtual teams more common also provide ways to simulate the benefits 
of face-to-face collaboration. Let’s look at some examples. 


Videoconferencing and Live Chat These tools can be used to simulate a shared team environment and allow virtual 
stakeholders to chat and interact as if their colleagues were within earshot. 


Interactive Whiteboards These tools allow team members to share content with multiple locations and collaborate in a 
visual whiteboard-type environment. 


Instant Messaging (IM) Instant messaging allows people halfway around the world to communicate instantaneously 
with ease. 


Presence-based Applications These applications extend IM capabilities by managing the status of participants to create 
a virtual office environment for sharing information. 


Virtual Kanban Boards These allow for the use of a Kanban board with a virtual team. Kanban boards are discussed in 
the “Communications” chapter. 


There may be questions on the exam that: 
+ Ask why virtual teams might be necessary 
* Describe situations that involve acquiring and managing virtual teams. 


* Describe a situation in which choosing the correct answer depends on your understanding that a virtual team might 
require a different approach than a colocated team. 


Individual and Team Assessments 
The best assessments are only useful if we put them to work to improve performance. Here are some practices through 
which the project manager can help the team to develop into and remain a high-performing team. 


Individual Assessments The more the project manager knows about each person on the project team, the easier it is to 
build trust, improve team communication, and encourage cooperation among team members. Personnel assessment tools 
can help the project manager learn more about team members by revealing how they make decisions, interact with others, 
and process information. This information can provide insight into how to lead and guide the team. Formal and informal 
assessment of team members by the project manager should continue throughout the project. 


Team Assessments The project manager completes formal and informal team performance assessments as part of 
developing the project team. These assessments are meant to evaluate and enhance the effectiveness of the team as a whole. 
They may include an analysis of how much team members’ skills have improved over the course of the project; how well 
the team is performing, interacting, and dealing with conflict; and how they are progressing through the stages of team 
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development. The assessments also help identify needed support or intervention by the project manager. Such assessments 
should be ongoing while project work is being done. The results of team assessments can be used to recognize the team’s 
progress or to motivate them to improve. Think of team performance assessment as looking at team effectiveness. The 
results of these assessments are also inputs to the Manage Team process, in which the project manager uses them to address 
issues identified. 


Hybrid Assessments One way to assess individual team members is to designate them as I-shaped or T-shaped. More 
information about these types is in the “Leadership Skills” chapter. 


Project Performance Appraisals 
Project performance appraisals are evaluations of individual team member performance. In this effort, the project manager 


collects information from team members’ supervisors and adjusts the project accordingly. It’s also important to understand 
that an appraisal might bring to the project manager s attention the need to provide additional training or encouragement 
to a team member. Note that the focus of this appraisal is on the individual’s performance of their assigned responsibilities, 
rather than on team performance. 

Because the Develop Team and Manage Team processes are performed at the same time, it is sometimes difficult to 
determine what happens in which process. For example, did you know project performance appraisals are performed as 
part of Manage Team, while the rewards and additional training indicated by the results of those appraisals are given as part 
of Develop Team? 


Key Performance Indicators 
Key Performance Indicators (KPIs) are measures used to review project performance. Project managers use KPIs to assess 


their team’s performance and help plan the project as it is ongoing. This is conceptually related to earned value measurement 
(EVM) for baseline performance (also called earned value analysis or EVA), which is covered in the “Budget and Resources” 
chapter. 

KPIs can be used to estimate the cost of the project at a given time. The following uses an agile focus as 
an example but this can be done on any project. 


¢ Rate of progress How many user stories and features is the product owner accepting per time period? 


¢ Remaining work How much work is left to complete? 

e Likely completion date This is the remaining work left to complete, divided by the current rate of progress. For 
example, the number of user stories (times their story point numbers) divided by the team’s current velocity. 

¢ Likely costs remaining This could be a simple salary rate for the team multiplied by the remaining weeks. On 
traditional or more complex projects this is likely to be a more comprehensive costing calculated to include personnel 
as well as equipment and other contracted costs. 


6.3 Exercise 

In your Exercise Notebook, write down the answer to this question: What does a project manager need to do to 
develop a team? Before looking at the answer, write down all you can think of for developing the team. The exam 
will emphasize your understanding of the interpersonal and team skills needed to be a good project manager. 
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Answer 


You may do some of the activities listed below on your projects, even if you may not plan them formally or 
consistently. Keep them in mind for the exam to help you understand the situations described and select the best 
answer choices. The project manager must ensure the team is working together as effectively and efficiently 
as possible. 


Checklist: Developing the Team 
o Use soft skills, such as mentoring, leadership, negotiation, influencing, and openness. 


o Seek to empathize, and practice active listening. 


a 


Encourage teamwork. Lead by example. Be a project leader, but be a peer, too. 

Communicate honestly, effectively, and in a timely manner. 

Assess and act in harmony with team members’ strengths and weaknesses, learning styles, and preferences. 
Establish and maintain trust among team members and all stakeholders. 

Collaborate to create a shared vision. 

Use participatory decision-making where possible; work to find mutually beneficial solutions to issues. 
Embrace cultural differences and capitalize on them for enriching team life. 

Hold team-building activities. 

Help foster a sense of team identity. 

Set realistic goals. 

Provide training for team members as needed. 

Support the upholding of agreements made with the team charter. 

Allow team members to resolve conflict on their own but assist with resolution when needed. 

Make the environment one full of recognition and rewards. 

Co-locate the team if possible; work hard to support virtual teams. 

Facilitate team communication. 


op o 20-0 t Ee, 6 bb bb boo B 


Evaluate and work to improve team performance; be creative and also get team involvement. 


Artifacts of Develop Team 
The outputs of the Develop Team process include: 


+ Results of assessments * Organizational process asset updates 

+ Change requests m/ Training requirements changes 

+ Updated project documents 
>/ Team charter 


>/ Newly adopted team-building exercises 


+ Revisions to existing templates for assessments 
-/ Lessons learned 


m/ Schedule 
-/ Assignments and resource calendars 
These results are direct inputs to the Manage Team process, the subject of the next section. Remember that they 
provide insight for the project manager toward continuous improvement of performance. If the project manager determines 


changes to plan documents affecting the performance measurement baseline are needed, they must process these through 
integrated change control. 
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Manage Team 


Manage Team involves the day-to-day management activities that you’re likely al- 
ready doing on projects, and you are probably very good at it. But it is important to 
solidify your knowledge from an exam perspective. 
First, we have our updated project management plan and documents from all 
other processes, not least of which is Develop Team. Details related to team- 
management activities are included in the resource management plan. Aside from 
those artifacts listed for the process of developing the team, other things that go into 
this maybe the: 
+ Issue log 
+ Project team assignments (possibly documented in a RACI chart) 
e Team charter 


+ Work performance reports 


The work performance reports provide an indication of project progress as compared to the project management 
plan. lhis information is used to identify necessary corrective actions. The project manager analyzes results from 
performance assessments to identify successes that need to be recognized, areas in which the team may need additional 
support or assistance, and issues or conflicts that need to be resolved in this process. Team members are also released as 
their work is completed. 

Here are some reminders of what to do during the Manage Team process, to help team members sustain 
high performance: 


* Observe what is happening + Look for conflicts team members cannot resolve on 
* Track and evaluate team performance their own 

+ Provide leadership * Facilitate conflict resolution 

+ Mentor team members * Negotiate and influence 

+ Plan and facilitate career development * Adjust plans based on performance data 

+ Deal with team issues + Manage risks to team success 


+ Use an issue log to track resolution 


Methods for Managing the Team 
Interpersonal and team skills are a primary method of managing the team, including conflict resolution, emotional 
intelligence, leadership, and influencing. Part of supporting a high-performing team is assessing how each team member is 
fulfilling their responsibilities. Project performance appraisals and progress tracking provide this information on individual 
team members. Earned value measurement (EVM), discussed in the “Budget and Resources” chapter, reflects how the 
project is progressing relative to planned progression. This is a window into how the team is performing (as well as whether 
the plan needs to change). 

Burndown and burnup charts are used on an agile project to track team performance. These charts can 


be part of the information radiators. Agile 
Focus 


Burndown Charts 

Burndown charts track work to be done on a project. As work is completed, the progress line on the chart will move 
downward, reflecting the amount of work that still needs to be done. They are commonly used to measure the team’s 
progress in completing the project work. A sample burndown chart is shown in figure 6.6. 


Burnup Charts 


Burnup charts track the work that has been completed. Therefore, over the course of the project, the progress line on a 
burnup chart will move upward, showing the increasing amount of work that has been completed. The big advantage of 
using a burnup chart is that it can show changes in scope, making the impact of those changes visible. A sample burnup 


chart is shown in figure 6.6. 
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Note: Keep in mind that this is also a very important tool for controlling scope, schedule, and cost. Rather than 
repeating the information in each of those chapters, it will be cross-referenced from this chapter. 


XYZ Project - Estimated Effort Remaining a ae 
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Story points 
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Estimated Effort (Hours) 


FIGURE 6.6 Burndown chart (left); burnup chart (right) 


Every project is different and presents unique challenges to the project manager. Factors such as the size and makeup 
of the team, the experience level of the team, and the complexity of the actual project work must be considered by the 
project manager in their efforts to get the best from the team. 


Think About It. If you were an observer of your project management work, what would you see? Do you tend 

to busy yourself with reports rather than really seeing what the team is doing, how team members are interacting, 
s what they feel is missing or doesn’t work, and what may be generating problems? Whether your team is colocated 

or virtual, paying attention to the tone of interactions, including emails and phone conversations will tell you 

more about what is going on than simply analyzing data. A project manager should observe what is happening 

and talk to people to understand how things are going. 


Artifacts of Manage Team 
The outputs of the Manage Team process include: 
* Updated project document 
vV Issue log 


V Lessons learned 


* Enterprise environmental factors like human resources evaluation systems 
* Organizational process assets like human resources appraisal templates 


+ Change requests (resource needs, costs, schedule or any part of the project management plan) 


Plans for releasing team members are included in the resource management plan. Because the length and focus of 
assigned work varies, team members may be released at different times throughout the project, as their work is completed. 


Issue Log 


Many project managers use issue logs, also known as issue registers or action item logs, to record problems and their 
resolutions. Because it is updated to reflect new issues as well as the resolution of issues, it is frequently an input and an 
output of the same processes. 

As part of managing team members and stakeholders, the issue log can be used to communicate about issues on the 
project. It facilitates the assessment of the causes of issues, the impact of issues on scope, schedule, cost, risk, and other 
aspects of the project, and the recommendation of corrective actions that could be taken. Such a log indicates to people 
that their needs will be considered, even if they are not addressed at the time the issue arises. Effective project managers 
control issues so they do not impact the project. The issue log is updated as part of project documents updates throughout 
the project. 
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An issue log might look like the one shown here. 


Date Raised Person Resolution Date 
Issue # Issue Added By Assigned Due Date Status Resolved Resolution 


FIGURE 6.7 Issue log 


An issue log should be customized to meet the needs of the people who will be using it. For example, an issue log 
could include more detail—such as a description or the category of the issue (such as team, schedule, or technical)—as 
preferred by the team. 


Putting It All Together 
a a a 


Be diligent when you study this and the previous chapter. Many students think this is an easy topic and do not study 
enough. For the exam, you should know the different motivational theories, management styles, understand servant lead- 
ership, emotional intelligence, and how to manage conflict. 


Review the QuickTest to make sure you understand these concepts and that you don’t have any gaps in your 
knowledge. Then complete this exercise. 


6.4 Exercise 
For each Resource Management process, give an example of the work the project manager on the library project 
should perform. Write the answers in your Exercise Notebook. 


Resources Process 

1. Plan resource management 
Estimate activity resources 
Acquire team 


Develop team 


AE Ue a 


Manage team 
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Did you come up with some of these? You may have identified some other examples. 


Resources Process 


1. Plan resource management 


2. Estimate activity resources 


3. Acquire team 


4. Develop team 


5. Manage team 


Example of work 

Since the city has few employees available to help with the project, the project 
manager will identify companies who can provide the needed talent to the team. 
The project manager requested public records for the last two libraries built in 
the same county as this one to research the time and costs used. 

The project manager used past library construction records to list the skills 

needed for the team. These skills were provided to the outsourcing companies. 
Resumes were reviewed for matches to the needed skills. The head librarian 
assisted with evaluating potential workers. 

Schedule training in cyber security for the IT team. 

Bi-weekly meetings with key team members are scheduled to check on progress 
and outstanding issues. 


The following exercise tests your knowledge of some typical roles on a project. Do you remember the discussion on 
project roles in the “Project Management Foundations” chapter? Your understanding of that content will impact how well 
you do on this exercise. You may want to review those pages before starting this exercise, or use the information in that 


chapter to fill your gaps. 
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6.5 Exercise 

Here or in your Exercise Notebook, write the initials of the key role responsible for solving each of the issues listed. 
Because much of the confusion for students is between roles of team members (T), the project manager (PM), the 
sponsor (SP), and the functional manager (FM), this exercise is limited to those roles. 


Consider what you have learned about project roles and remember to keep matrix organizations in mind when 
reading through these situations. 


Situation 
Two project team members are having a disagreement. 
There is a change to the overall project deliverable. 
A functional manager is trying to pull a team member off the project to do other work. 


The project manager does not have the authority to get things done. 


i 
2; 
3. 
4. 
5. There are not enough resources to complete the project. 
6. The team is unsure of what needs to happen when. 
7. An activity needs more time and will cause the project to be delayed. 
8. An activity needs more time without causing the project to be delayed. 
9. A team member is not performing. 
10. The team is not sure who is in charge of the project. 
11. There is talk that the project may no longer be needed. 
12. The sponsor provides an unrealistic schedule objective. 
13. The team is in conflict over priorities between activities. 
14. The project is behind schedule. 
15. A team member decides another method should be used to complete their activity. 
16. The project is running out of funds. 
17. Additional work that will increase cost (not identified during the risk management process) 


is added to the project. 
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This exercise is designed to help you answer situational questions on the exam dealing with roles and responsibilities. 


If you disagree with some of the answers, make sure you are not reading something into the question, and assess 
whether it indicates a gap in your project management knowledge. 


Make sure you have a clear understanding of how stakeholder, communications, and human resource management 
relate to each other. This will help you answer questions correctly on the exam. 


Role Explanation 


t PW 


2. SP 


5. SP/FM 


TSP 


9. PM/FM 


10. SP 


11. SP 


12. PM/SP 


14. PM 


15. T 


16. SP 


17. SP 


People involved in a conflict should attempt to resolve it themselves. 


A change to the overall deliverable is a change to the charter. Only the sponsor can approve 
changes to the project charter. 


Assume project management is done right (unless an exam question tells you otherwise). The 
project manager gives team members enough information (e.g., schedule, network diagram, 
project management plan, identified risks) so they can manage their own workloads. The word 
“trying” denotes this situation is occurring in the present. If it said “has pulled,” the answer 
would be the project manager. 


Read situational questions carefully. 
It is the sponsors Tole to give the project manager authority via the project charter. 
The sponsor and functional manager control resources. 


The project manager takes individual time estimates, combines them into the project schedule, 
and communicates that schedule to the team. 


The project completion date is most likely in the project charter. Notice the word “will.” This 
means the evaluation by the team is completed and there is no available reserve. Any such 
changes are changes to the project charter and require sponsor involvement. 

It is the project manager's role to look for impacts to the other project constraints. (Think 
about integrated change control here. It may need to be used but we don’t know since the 
indication is that the schedule baseline is not to be affected.) 

The project manager (and the team member's functional manager) share responsibility for 
directing resources. 

The sponsor designates the project manager in the project charter. 

The sponsor protects the project from a large change like termination. If it becomes clear that 
the project will not meet organizational objectives the sponsor will authorize termination. 

Only the sponsor can make a change to the charter (including a schedule constraint). The 


project manager must provide evidence that it is unrealistic and work with the sponsor to 
resolve it. 


It is the project manager's role to settle such conflicts (and ensure a network diagram and 
critical path are established). 

The project manager is responsible to control the overall project schedule. 

A team member has control over their activities as long as they meet time, quality, cost, and 
scope objectives in the project management plan. The team member must keep the project 
manager informed of method changes, however. As appropriate, the project manager can 
integrate method changes into the project and look for unintended impacts. 

It is the sponsor s role to provide funding for the project. 

Additional work not identified in the risk management process means it was not included in 
the original project budget (or contingency reserve). The sponsor must be involved in 
providing additional funds. 
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Domain II: Process 


The Examination Content Outline (ECO) specifies that Domain II covers 50% of the exam. The Process domain includes 
the technical project management skills, methods, and the activities needed to manage a project and deliver the benefits 
for which the project was undertaken. In this section, you’ll find the following chapters: 


+ Scope * Communications 
+ Schedule + Risks and Issues 
+ Budget and Resources e Procurement 
* Quality of Deliverables and Products * Stakeholders 


Managing project governance, artifacts, issues, changes, the use and transfer of lessons learned, and product turnover to 
operations are also part of this domain. 
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Introduction 


You already know that a project must, from start to finish, help to achieve the goals and objectives for 
which it was selected. Eliciting and analyzing requirements, defining project and product scope, and 
then building and delivering that scope in accordance with those requirements are all at the heart of 
this value delivery system. 

The goals for delivering project scope are the same regardless of the project life cycle and delivery 
approach. When managing scope, a project manager must define what work is required and then 
ensure all that work—and only that work—is completed. This is generally an easy topic, but we all 
have gaps in our knowledge. Be sure to review the Quicktest and make note of your gaps so you can pay 
particular attention to those sections in this chapter. 

In addition to reviewing the Quicktest, see if the following list helps you uncover gaps in your 
knowledge. 


IEUU Things to Know about Scope Management for the Exam 


OF THE EE The project manager must plan how they will determine the scope, as well as how they 
TRADE will manage and control scope. This is part of the scope management plan. 


+ Scope must be clearly defined and formally approved before work starts. If using an 
adaptive approach, this may be done at a higher level with a summarized agreement. 

+ Requirements are elicited from all stakeholders, not just the person who assigned 
the project. 

+ Requirements elicitation can take a substantial amount of time, especially on 
large projects. 

+ Requirements must be evaluated against the business case, ranked, and prioritized to 
determine what is in and out of scope. 


+ A work breakdown structure (WBS) is utilized on all projects that use a predictive 
approach. Using this tool enables the project manager to clarify identified scope as well 
as find additional scope. 


+ A backlog, an agile alternative to a traditional WBS, may be utilized on projects using 
adaptive approaches. A backlog creates visibility into the scope as well as the overall 
priorities of the project because a backlog is ranked in priority order. 


+ While the project is being completed, the project manager must check to make sure all 
the work included in the project management plan is being done—and only that work. 


* Gold plating a project (adding extras) is not allowed. 


+ Any change to scope must be evaluated for its effect on schedule, cost, risk, quality, 
resources, and customer satisfaction. 


* On plan-driven projects, changes to scope require approval; scope changes should not 
be approved if they relate to work that does not fit within the project charter. 


* Scope priorities and changes are more flexible on agile projects where work is planned 
and completed iteratively and incrementally, but change is not free. This means that 
when scope is added, the backlog is reprioritized and earlier prioritized items move 
below the new scope that has been added. It is possible that some scope on the bottom 
of the backlog will be pushed to another release or another project to preserve cost and 
schedule baselines. 
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+ Hie project manager and the project team should continuously determine what is and is not included in the 
project scope. 


+ Internal verification followed by customer acceptance of deliverables happens throughout the project. 


Definitions Related to Scope Management 
It’s important to understand the distinction between product scope and project scope. Those definitions follow, along with 
a few more definitions we want to start you off with for understanding the chapter content. 


Product Scope 


Product scope can be defined as the product deliverables with their associated features and functions. Another way to say 
this is: The requirements that relate to the product, service, or result of the project is the product scope. It answers the 
question, “What end result is needed?” There maybe a separate, preliminary project to determine product scope, or the 
requirements may be defined as part of the project, depending on the needs of the project and the organization. 

Example Let’s say the project is to build a new train terminal. The product scope is “a train terminal that meets these 
technical specifications.” The technical specifications would be complex and comprehensive as defined by qualified subject 
matter experts. To determine if the project successfully achieved the product scope, the new train terminal is compared to 
the specifications, which were recorded in the requirements documentation and the project scope statement for the 
project. All aspects of the train station would need to be tested to ensure they work according to plan before the train 
station is accepted as complete and turned over to operations. 


Proj cope 

The project scope is the work the project team will do to deliver the product scope. It includes the product scope. For the 
train terminal example, the project scope would be “a train terminal that meets these technical specifications,” plus the 
management and delivery of all the work to deliver the train terminal. In other words, project scope includes the planning, 
coordination, and management activities that ensure the product scope is achieved. These efforts become part of the scope 
baseline and scope management plan, which are parts of the project management plan. 


Iteration 

On agile projects, this is a specifically set period of time during which a project team refines plans or builds ~N 
the product of the project. In the context of planning, plans are iterated and refined as new information ( A ) 
becomes available. In the context of scope, the team builds the product in increments during fixed periods of 4 
time called iterations (or sprints, in Scrum). Iterations are set in specific “timeboxes.” (See timeboxing next.) Focus 
Timeboxing 


For an agile project a timebox is a short, fixed period of time set for the team to complete a selected and prioritized set of 
activities. In the context of scope this can translate as the completion of a specific set of stories during a two-week iteration 
(or sprint), for example. If the work planned for the iteration isn’t complete within the two-week iteration, the team leaves 
the uncompleted work on the backlog to be undertaken during another iteration. So it is the timebox (the iteration) that is 
honored. There is no “complete all the stories no matter how long it takes” approach. 


Minimal Viable Product (Minimal Marketable Feature or MMF) 

The term “MVP,” or minimal viable product, refers in agile to an increment of product that is at least useful enough that the 
customer can potentially take delivery of the MVP and use it while the team continues to build the rest of the product. We 
say “potentially” here because while the team can show the customer the MVP, the customer can sign off on it and accept 
delivery of it and use it. Alternatively, the customer can accept it, sign off on it, and wait for additional MVPs to be added 
before taking delivery. These valuable but partially completed products are also known as minimal marketable features, or 
MMEs. A product release will typically have several MMFs integrated together, but what is included is up to the customer. 


Example The customer could take delivery of a skateboard that has the potential to be electric. They could then use 
it without the electric components, and have it upgraded once the electrical features are ready. They could later decide if 
they want the already available handles, which are optional, but while they are waiting for the team to build the electrical 
components for installation, they have the value of using the skateboard in its basic form, its MVP. 
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Scope Management Overview 


For the exam, you need to understand the scope management process from the perspective of the Process Groups model 
as well as from the perspective of an adaptive environment. You also need a solid understanding of how these models fit into 
the concepts found in the Examination Content Outline (ECO) and the PMBOK* Guide. 


The Examination Content Outline (ECO) and Process Groups Model 
The ECO’s Process domain shows a task called Plan and Manage Scope, which is analogous to the Process Groups model’s 
Scope Management process. This is illustrated in the first two columns of the following chart. 


Process Groups Model PMBOK® Guide 


Domain II Scope Management Domain 2.4 
Planning 
Task 8 Plan Scope Management Domain 2.6 
Plan and manage scope Collect Require m Delivery 
Scope eneng Domain 2.7 
Deine Measurement 
Create WBS Domain 28 
Validate Scope Monitoring will 
Control Scope & Controlling 


Now, only one task is listed in the ECO column above. Does this mean that only “Plan and manage scope” in the ECO 
is relevant to the Process Groups models planning and monitoring and controlling of scope, regardless of the project 
attributes and the selected project life cycle? Of course not. It would help you to hold the ECO in your hands right now or 
to have it open on your computer as you work through this section of the chapter. Thinking holistically, you may have 
already identified that the ECO task, “plan and manage quality of products/deliverables” is intimately tied to managing 
scope. The team also uses the schedule and budget to create the scope. 


First, remember that many or all People domain skills are used to manage all project constraints, since the project 
manager works with others to get things done. Now, review the following examples and skim through the ECO to think 
about how these and other tasks fit together with the plan and manage scope task. Think about the ECO tasks holistically. 
These are just a few examples of other ECO tasks helpful in managing scope: 

+ Scope management relies on the project manager’ s work to ensure that team members/stakeholders are adequately 
trained (domain 1, task 5). Regardless of whether there are generalizing specialists for an agile project or specialist 
team members for a plan-driven project, the project manager identifies what training is needed and provides it as part 
of supporting team performance and addressing and removing impediments (People domain, tasks 4 and 7). 

e Look at the ECO’ s Business Environment domain, task 2: Evaluate and deliver project benefits and value. This is 
about balancing competing constraints, including cost, time, and quality in order to build product scope. 


Requirements for the most part are defined early in a plan-driven project, while on an agile project it is understood 
that scope emerges and more requirements gathering with stakeholders is necessary over time. Figure 7.1 is a visualization 
of scope management at a high level from the Process Groups model perspective. It can help you visualize where you are 
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in the scope management process as you continue with this chapter, and understanding it will help you on the exam as you 
read scenario questions. 


Key 
Continuous change contro! 
is consistent with all 
approaches 


Change prompts a process 
( » to be reiterated through 
progressive elaboration 


or agile methods 


+-- > Changes that cause a 
return to Initiating are rare 


Remember, 
it's iterative 


FIGURE 7.1 Scope management process 


Plan-driven Scope Management 


There are a lot of acceptable ways to manage scope. If you do it differently than described here, you are not necessarily 
wrong. For the exam think of the scope management process as including the following for predictive project management: 
1. A plan is developed for how to plan, validate, and control scope and requirements. 
2. Determine requirements. Ensure they support the projects business case (as described in the project charter)— 
the benefits and value the project is meant to deliver (Business Environment domain, task 2). 


. Analyze and balance stakeholder needs to determine scope. 


3 
4. Create a WBS to break the scope down to smaller, more manageable pieces. Define each piece in a WBS dictionary. 
5. Obtain validation (signed acceptance) that the completed scope of work is acceptable to the customer or sponsor. 

6 


. Measure scope performance and adjust as needed. 


No one can request or add work that is not related to the reason for initiating the project. Yet, in your real world, do 
people want work done and try to attach it to any project they can to get that work accomplished? Do you see scope on 
projects that doesn’t support the company’s business objectives? It happens all the time. Change control is about protecting 
the project from unapproved changes in a predictive environment. 

When taking the exam, assume you have the authority in a predictive environment to say no when someone tries to 
add unrelated scope to your project. This is important to internalize because so many of us do not have this authority in the 
real world. 

Note that in a predictive environment, creating a work breakdown structure (WBS) is a required part of project 
management. If you have never created one or do not currently use a WBS on your projects, this chapter will help you 
understand how beneficial this tool is and what it can do for you. Remember, the exam asks questions at an expert level and 
assumes you have experience using various tools. 


156 


SEVEN Scope 


Agile Scope Management 


In adaptive environments, scope management looks like this: 


1. Requirements are identified and documented at a sufficient level of detail so they can be prioritized 
and estimated at a high level. 
2. The products’ features—collectively the product scope—are kept in a list called the product backlog. 


. The work is broken into product releases. A project may include one or more releases. 


Bw 


. For each release, the work is completed through iterations (specifically defined periods of time, like two weeks, or 
three weeks, for example). 

5. The work of each iteration (and release) is defined successively in more detail just before the work for each iteration 

begins. In this way, decisions are deferred to “the last responsible moment.” 

Product scope is typically more flexible in agile projects than it is for plan-driven projects. As essential product 
features are delivered in early agile releases, more optional features may be deferred. 

Example You are buying a new, custom-made electric car. You travel a lot, so you want the front seats to recline into 
beds so you can pull into a campground to sleep. Your budget doesn’t support these adaptive seats right now, but you need 
the car right away. Neither your budget nor timeline support the self-driving features that will eventually allow you to nap 
while the car drives autonomously on a long road trip. So the electric car company builds the basic car and delivers it 
quickly in Release 1. Later, for another release, you return for installation of a few more custom features you have agreed 
upon with the car builder. Eventually you will come back for the adaptive seats when the price goes down and you have the 
money and time for their installation. 


Early agile practitioners came from the software development industry. They were keenly aware that most 
software users actually use only a small percentage of the features of a given software package. So they thought 
why wait for the entire package to be built when the most valuable features can be used right away (while delivering 
a large feature set is notoriously difficult to do on time) ? They recognized what became an agile tenet: a distinct 
advantage of an adaptive environment is the value saved on the features not built. In other words, part of delivering value 
is deciding on what work is not done (immediately, or possibly ever). 


In our example above, what if later you decided your car did not need seats that reclined into beds? You could cancel 
that feature and just stay with the basic car. If you did decide to get that feature later though, the chances maybe good that 
you will be buying an improved feature that has also become more economical. 

Note: For a plan-driven project life cycle you will definitely need a WBS, while in a more change-driven life cycle you 
may have a WBS, the product backlog may take its place, or you may have both. Look for evidence in exam questions that 
tells you which type of life cycle you are dealing with. 


Desired Outcomes of Scope Management 
Assume for the exam that scope is properly planned and managed unless information in an exam question indicates 
otherwise. This means that the following outcomes should be expected as a result of scope management: 

* Throughout the project, the project team has a clear understanding of product and project requirements or they have 
the ability to make those requirements clear through interactions with the project manager and stakeholders. 

+ Throughout the project, data are gathered and earned value measurement is performed to indicate project progress 
relative to plan. This allows the team and stakeholders to best manage target results and make adjustments where 
necessary. This may take the form of traditional earned value measurement for plan-driven projects (see the “Budget 
and Resources” chapter). For agile projects, teams may use burnup and bumdown charts (see the “Build and Support 
Performance” chapter). 

e Project scope as agreed to by the performing organization and its stakeholders is delivered on time, within budget, and 
with sufficient levels of quality, as agreed to with the customer. 

* Scope can be readily controlled, verified internally, and validated with the customer. Scope and quality management, 
along with stakeholder engagement and stakeholder expectation management, lead to customer satisfaction with 
project progress. 


* The customer is satisfied with project deliverables. 
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Scope Management Planning 


Together, the requirements and scope management plans provide direction on how the project and product scope will be 
defined, managed, and controlled. The project charter, project life cycle, and development approach descriptions, and or- 
ganizational process assets are all inputs to the process of planning scope management. The development approach influ- 
ences how requirements will be elicited and how the scope statement will be developed. 


Scope Management Plan 
The scope management plan, which is the primary artifact of planning scope management, is part of the project management 
plan. The project manager uses it to guide the building of the product until closing. It details how scope will be planned, 
executed, and controlled. It describes how to do the following: 

+ Achieve the overall project scope 

+ Create the WBS and WBS dictionary, or product backlog and stories 

+ Manage and control scope to the project management plan 


* Obtain acceptance of deliverables 


Each scope management plan must be tailored to the particular project, but it may cover topics that can be standardized 
for a company or for a particular type of project. Therefore, organizations often utilize templates, forms, and accepted 
standards for scope management. These are examples of organizational process assets. 


Requirements Management Plan 
In addition to describing the methods the project manager intends to use to identify requirements, the requirements 
management plan should answer the following questions: 

+ Which requirements techniques will be used to analyze and document the requirements? 

* Once I have as many requirements as I can gather, what will I do to analyze, prioritize, manage, and track changes? 


+ What should I include in the requirements traceability matrix? (Described later in this chapter.) 


The requirements and scope management plans can be developed in stages or iterated during project planning. The 
first step is to plan how scope will be defined and who will be involved. Planning decisions will then become part of the 
scope management plan. Later planning efforts may result in scope being added so the process is iterative. For example, the 
completion of the Plan Risk Responses process means these risk responses are part of the project scope, causing a new 
iteration of the scope management plan, scope statement, and WBS, or the product roadmap and backlog, for agile. 


Agile Scope Planning 


Project and product planning is more iterative on agile projects than it is on plan-driven projects. Specifically, p~ 
iterative product planning happens first at a high level during product visioning. Then the team begins to A | ) 
decompose the product into a backlog containing stories, which may be decomposed further. Once Agie 


decomposition happens, the product roadmap is created in more detail. Finally, the team plans for Focus 
each iteration. 


Agile Visioning 

We discussed product visioning in the “PMP* Exam References in Context” chapter. This is about establishing a common 
understanding of what the product is, what it does, and creating a succinct way of describing it and the value it delivers. 
This is often referred to as an “elevator statement,” since it should be short enough to describe in a short elevator ride. 


Agile Product Roadmap 


A product roadmap alone is not the agile equivalent of a plan-driven scope management plan, but it is a visual representation 
of the product s'main components, broken into sequential product releases. It also acts as: 


+ A communication tool that provides stakeholders with a high-level view of the intended functionality of each release 
+ A high-level planning tool with the assumption that there will be changes to it 


+ A tool that allows you and the team to go back to confirm (and change) roadmap components over time 
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The roadmap and backlog work together like this to help the team plan the project: 
* The roadmap shows how the product will grow by release. 


+ The backlog further breaks down the features in each release into smaller, more manageable pieces called stories. 


The product roadmap and backlog influence each other, and changes to project priorities or requirements are reflected 
on both. Figure 7.2 shows one way a product roadmap might look for a software product that allows the consumer to 
manage appointments and bills on their health clinics’ website. The “(P)” following some of the entries indicates a planned 
partial completion for that release, while “(C)” indicates a planned full feature completion. You will also notice at the 
bottom of column one that there are often “stretch” goals, which are agreed upon. This means that if the team finishes the 
stories for the release more quickly than anticipated they will work on the stretch goals, but the customer is already aware 
that it is a stretch and may not be completed or even started for that release. 


Release 1 Release 2 Release 3 
” i 5 ; Patient can manage insurance and 
Comply with lati P Comply with lati C 
‘omply with regulations (P) ‘omply with regulations (C) payments 
R a r Patient can view their data from 
Branding/style schemes User interface design (UID) m iP 
other institutions (P) 
Database integration (phase 1) Database integration (phase2) 


Patient can change personal data 


Site securi 
y and preferences 


Manage web accounts (login, , : 
Patient can manage appointments 

password, etc.) (P) 

Patient can view own medical data Patients with edit access could 

(P) damage the database RISK _ 

Current website capacity may not 

be enough RISK 

System architecture RISK. 

Conduct outreach marketing 

campaign (stretch) (P) 


FIGURE 7.2 Patient client portal project roadmap example 


Agile Product Backlog 


A product backlog is a single, visible master list of all functional and nonfunctional work identified for the project. In other 
words, a backlog is a list of work that needs to be done. Backlog stories have a description of each piece of functionality and 
are reviewed for risks by the team. They are prioritized by the product owner (as an integral team member). A story should 
also include the following information: 


+ The business benefit 
* Definition of done for determining when it is complete 


+ Acceptance criteria for determining under what conditions (requirements) it will be accepted by the customer (like 
scope verification and validation) 


* The stakeholder who requested it 


Here is the principle behind the building and prioritizing of stories: 


+ The product owner organizes the backlog by priority from the top down. 


+ The highest value stories are always at the top, from which the development team pulls to build the product. 
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+ While the product backlog contains all the formally recognized scope, low-priority items at the bottom of the backlog 
may never be developed if the cost or time to produce them is deemed greater than the value they would return. 
Because scope is emerging, this is sometimes not known until later in the project. 

e Initial backlog prioritization happens early during release planning and then later again during iteration planning. 

+ The team builds stories for a current iteration while the product owner refines and reprioritizes the backlog for the 
next iteration. While doing this, the product owner also answers questions for the current iteration. 


Figure 7.3 shows an example product backlog for the healthcare clinic patient website. Some additional functions of 
the backlog include: 


+ A single source of information about the project to aid in effective communication and provide a visible artifact of the 
projects scope and status. 


+ A tool for continually updating scope as the project progresses and new information becomes available. 


# Features Stakeholders 
Pl Manage appointments Patients, administrators, practitioners 
Change personal data and : = oe 
P2 ee P Patients, administrators, practitioners 
preferences 
View health information i P 
P3 J Patients, practitioners 
library 
Outreach (marketin; 2 A 
P4 ; ( 8) Patients, marketing 
campaigns 
Practitioner and patient s oe e 
PS cor Patients, practitioners, marketing 
communications 
P6 Regulation compliance Patients, government 
View patient’s own medical ` i: ae 
P7 Patients, administrators, practitioners 
data from The Center 
View patient’s own medical r za aye 
P8 A Patients, administrators, practitioners 
data from other institutions 
Manage web accounts F P 
P9 a 8 Patients, administrators 
(login, password, etc.) 
FIGURE 7.3 Partial product backlog for patient web page 
Iteration Planning 


After release planning and the product backlog is created and prioritized, the team, including and importantly the product 
owner, decide which increments of the product will be built during the first iteration. Then as each iteration is successfully 
completed the product owner has already prepared the stories to be built for the next iteration, and so on throughout 
the project. 


Hybrid Project Planning 

Parts of hybrid projects are plan-driven, and parts are planned and delivered using agile methods. For example, let’s say 
there is a large, complex product that needs a complex variety of working features, like a control system for a new solar 
energy-based community. This system may need to be built using a plan-driven approach, while the rollout of the solar 
panels may be done iteratively using agile methods as new homes are completed in the community. The design, build, 
testing, and installation of the control system in the community building would be done using a WBS while the solar panel 
systems for the individual homes could use lists, like backlogs, that would be customized per customer. 
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Often, in mixed corporate environments, projects using a hybrid approach will have a WBS (or similar tool). Work 
will be broken down to a certain level and will be used to share information with the PMO or executive management, who 
may be accustomed to predictive approaches and traditional documentation. A backlog may then be used for organizing 
work with the team. The project manager acts as an interface between groups. 


Eliciting and Analyzing Requirements 


Stakeholders can often describe a problem they have or an opportunity they want to 
take advantage of. Yet it is difficult or impossible for them to describe the solution. 
Business analysis is needed to help the project team elicit and analyze requirements 
before product and project scope can be fully defined. Requirements are the product 
features, or what stakeholders need from the product and from the project. The “Col- 
lect Requirements” process, as it was named in the Process Groups model, looks for 
all requirements, not just those related to the product. The process of eliciting and 
analyzing requirements is critical to project success, as a missed requirement could 
mean significant changes and conflict throughout the remainder of a project. 

Note: The term “elicit and analyze” requirements better represents the 
magnitude and importance of this process. However, when referring to the historical 


name given to this process in the PMI Process Groups model, we will use “Collect Requirements.” You may see either term 
on the exam. 


The objectives for which the project was initiated were originally the result of a Needs Assessment process that would 
have taken place to help establish the business case for the project. Using this information, all requirements should relate 
to achieving these objectives, as outlined and approved via the project charter. They may include requests about how the 
work is planned and managed. 


Example A stakeholder could request that systems not be shut down during peak business hours to accommodate 
a project. 

Requirements include the capabilities stakeholders need from the product, such as a software application that opens 
at a set time when it has updates for the user. But requirements can also be non-functional, in categories related to the 


following examples: 
e Quality The component D must be able to withstand 200 pounds of pressure. 
¢ Business process You must track and report the project’s expenses in this way. 
e Compliance By law, we have to meet this safety standard. 
e Project management We require risk management procedure X to be used. 


¢ Environmental consideration Results of the full environmental impact study must be followed so the project has 
no negative impact on the environment. 


° Social need The new transit line must have accommodations for people with disabilities who cannot drive cars. 


Functional requirements are also often designed to answer specific questions, like the following: 
¢ Business requirements Why was the project undertaken? What business need is the project intended to address? 
° Stakeholder requirements What do stakeholders want to gain from the project? 


e Solution requirements What does the product need to look like? What are its functional requirements (how the 
product should work) and nonfunctional requirements (what will make the product effective)? 


¢ Transition requirements What types of handoff procedures or training are needed to transfer the product to the 
customer or organization? 


e Quality requirements What quality measures does the product need to meet? What constitutes a successfully 
completed deliverable? 


¢ Technical requirements How will the product be built? What are the product specifications? 
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Agile methods do not attempt to specify fully detailed requirements up front. Agile teams initially IN 
define requirements at a high level and then progressively refine them. This approach delays decisions on (A) 
implementation details until the last responsible moment, helping to avoid or lessen the effect of change Ll Agile 

Focus 
requests. 


Think About It. The “Collect Requirements” process involves using the following inputs to create the 
requirements documentation and the requirements traceability matrix. These are artifacts needed in order to 
elicit and analyze requirements for a plan-driven project. Review them and think through how each may help to 
elicit and analyze requirements. 


¢ Project charter The Collect Requirements process begins with descriptions of the high-level requirements in the 
charter. More detailed input from stakeholders is part of the reason for Collect Requirements. 

e Assumption log This documents known stakeholder assumptions related to product and project requirements. 
Eliciting and analyzing requirements includes refining and adding to this list. 

¢ Stakeholder register Created in initiating, this includes a list of stakeholders identified thus far, as well as their 
requirements and expectations. 

e Agreements Buyers’ requirements are documented in contracts if the project includes procurements. Agreed-upon 
requirements included in letters of agreement internal to the organization are also a source of requirements. 

e Organizational process assets Examples of these could be historical records and lessons learned. These may 
provide information about requirements from past, similar projects as well as information that may identify commonly 
overlooked areas of scope. 

¢ Stakeholder expectations The Collect Requirements effort also includes eliciting stakeholders’ expectations— 
their beliefs or mental pictures about how the project will turn out—and translating those expectations into 


requirements as necessary. Not all expectations are requirements so this is an area requiring trust and effective 
stakeholder communication. 


On large projects, there could be hundreds of stakeholders, and no single method of eliciting and analyzing 
requirements will work for all of them. Since missing a requirement can be costly, a concerted effort is made to find as many 
requirements as possible before work starts on a development phase. 


Methods for Eliciting and Analyzing Requirements 
The project manager needs to tailor their method choices to the project and its stakeholders. The following methods are 
representative examples of those used to elicit and analyze requirements. 


Verbal Requirements Elicitation Methods 
With conversational methods for eliciting and analyzing requirements, the exchange between the team—which may 


include a business analyst—results in written artifacts that are then used to define, plan, and manage project and 
product scope. 
Brainstorming Many people think this is just a meeting where people discuss ideas, but it is more than that. The purpose 
of brainstorming is to get people to share ideas on a topic, but importantly, to build on each other’s ideas. It can be highly 
beneficial to include people with different perspectives or backgrounds. The participants may be internal or external to the 
project and/or the organization. Here’s how it works: 
e One person mentions an idea to solve a problem or, in this case, elicit requirements and ultimately determine scope. 
No evaluation happens during the idea-generation period. 
+ The idea generates an idea from another participant, which leads to yet another idea, and so on. 
+ After the ideas have been captured, the group evaluates and ranks the ideas using the nominal group technique or 
multicriteria decision analysis (described later in this section). 


Interviews You may also see the term “expert interview” on the exam. The project manager and/or a team member 
interview stakeholders to elicit their requirements for a specific element of the product or project work, or for the overall 
project. These interviews take place between two individuals or in group settings. They may also be conducted via email or 
phone or using virtual collaboration tools. 
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Focus Groups This technique elicits opinions and requirements for the product or project from stakeholders and subject 
matter experts. Usually selected from a specific demographic group of customers, focus group members discuss their ideas 
with each other. The conversation is directed by a moderator. 


Questionnaires and Surveys These are typically used for large groups. Questions are crafted to specifically elicit 
requirements and expectations from respondents. 


Benchmarking This looks at what the competition is doing. Benchmarking focuses on measuring an organizations 
performance against that of other organizations in the same industry. Limitations on this include that it can be time- 
consuming and costly. It may also inhibit creativity because the focus is on examining solutions that have been used rather 
than on innovation. 


Facilitation This technique brings together stakeholders with different perspectives, such as product designers and end 
users, to talk about the product and, ultimately, define requirements. It uses a consensus approach, which achieves general 
agreement about a decision. Those who would prefer another option are willing to accept the decision supported by most 
members of the group. Facilitators sometimes use voting to help a group discuss various opinions. 


Voting Voting is commonly used for group decision making. Soliciting input about requirements from stakeholders often 
results in conflicting requirements. A decision-making process might have the goal of unanimous agreement. Or, when 
there are conflicting opinions, groups may take a majority approach, taking the decision that more than half of its members 
support. If there is no majority opinion, the group may go with the decision that has the largest number of supporters. This 
is known as the plurality approach. PMs should be careful making decisions based on majority rules in case key stakeholders 
are in the minority. 

Agile teams use voting all the time for group decision making but it may be more difficult to use with customers, in 
which case other methods should be used. 


Multicriteria Decision Analysis With this technique, stakeholders quantify requirements using a decision matrix based 
on factors such as expected risk levels, time estimates, and cost and benefit estimates. 


Nominal Group Technique This technique can be (but is not always) done during the same meeting as brainstorming. 
It follows these steps: 


+ A question or issue is posed 

+ All participants write down their ideas privately 
* Each participant shares their ideas 

* The group discusses what has been shared 


+ The group ranks the ideas based on which are most useful in the given context 


Observation This is a great way to learn about business processes and to get a feel for the work environment of stakeholders. 
This technique is useful for projects aiming to streamline a business process. It generally involves job shadowing—watching 
a potential user of the product at work, asking questions and, in some cases, participating in the work to help 
identify requirements. 


Prototypes A prototype is a model of the proposed product that is presented to stakeholders for feedback. IN 

The prototype may be updated multiple times to incorporate stakeholders’ feedback until the requirements ( A } 

have been solidified for the product. Agile 
Focus 


User Stories Stakeholders may help develop user stories during facilitated discussion sessions. Stories 
describe functionality or features that stakeholders hope to see. They are often written in the following format: 


Asa <role>, I want <finctionality/goal> so that ebusiness benefit> 


FIGURE 7.4 Story format 
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Example “As a community organizer, I want the library to offer public meeting spaces so we have a place to gather 
and show community members the library’s benefits through neighborhood events.” 


Other examples of facilitation sessions include the following: 
e Joint application design ( JAD) Used primarily in software development efforts, JAD sessions involve eliciting 
requirements and other input to enhance the process of developing the software. 


e Quality functional deployment (QFD) Also referred to as the Voice of the Customer (VOC), this technique is 
generally used in manufacturing to elicit and prioritize customer requirements. 


Graphic Requirements Elicitation Methods 
Different types of artifacts result from eliciting and gathering requirements, which will help to define, plan, and manage 
project scope. The following methods for eliciting and analyzing requirements result in graphic images, or different ways 


of representing project requirements. 


Mind Maps This is a way of diagramming ideas or notes to help generate, classify, or record information. It branches out 


of a central core as shown in figure 7.5. Colors, pictures, and notations can be used to ma 


e the diagram more readable. 


ee ‘Magazines 
. Small chaits—80% Aone area Reading area [Newspapers 
SP ior time cale M ———— Comtortable chairs —25 
Patrondesks—2 
Ceiling-mounted projector 150,000 books 
|Rooms Book storage / 15 different categories 
Medium—20 person =—= 
Saale Public meeting space Signage above for easy locatii 
——~ Separate entrance 
Drop-down screens Computers for public use—48 
Computers for visitors’ 
service desk—12 
Computers | Computers for = 
wi offices/cubes—2 


and music—2,000 sq ft uters with capability 
Shelves for audio books—15\_ Audio Each area—3 
Racks for music—12 


FIGURE 7.5 Mind map 


Context Diagrams Also known as a context level data flow diagram, a context diagram is frequently used to define and 
model scope. It shows the boundaries of the product scope by highlighting the product and its interfaces with people, 
processes, or systems. 

Figure 7.6 shows an example of a context diagram for the payroll system upgrade described in the project charter in 
the “Integration” chapter. 


tore tax Confirmation 
rates of receipt of 
funds 
~~ 
Tax payments ^ 7) Direct deposit 
instructions, funds 
Payments, witholding 
reports, benefit —. 
authorization S 
Profile, 
depe a ae 
ndents benefit plans 
Employee pay $ 


FIGURE 7.6 Context diagram 
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Think About It. Stop for a moment to think about how you might use the following two methods for eliciting 
: and analyzing requirements. You may initially create a context diagram with the help of stakeholders, to get 
a overall understanding of the product and who might use it. You may then use a combination of surveys, 
observation, and facilitated discussions with stakeholders to elicit their requirements. Then, as part of analyzing 
the requirements you have elicited you might sort them into an affinity diagram so that similar items are grouped 

together for further analysis into how they relate to the overall product. 


Affinity Diagrams This technique groups requirements (generated from other gathering methods) by similarities. This 
sorting makes it easier to see additional areas of scope that have not been identified. Figure 7.7 shows an example of an 


affinity diagram. 


Library Project Requirements 


Book storage Computers Office space Customer service 


Children’s area Reading area Public meeting space 
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Artifacts of Eliciting, Analyzing, and Balancing Requirements 

Important aspects of eliciting and analyzing requirements are balancing them against one another, resolving conflicts 
where there are competing requirements, and, finally, completing the requirements artifacts, so they will help you with the 
next process, which is Define Scope. 


Balancing Requirements 
Part of balancing stakeholder requirements involves making sure the requirements can be met within the project objectives. 


If they cannot, then the project manager needs to look for options to adjust the competing demands of scope, time, cost, 
quality, resources, risk, and customer satisfaction. 


This is never easy or fast. It can become impossible if there aren’t clear project objectives. Do you try to get as close to 
final requirements as possible when managing projects? Are your requirements ranked by order of importance? If not, 
think about how such actions could improve your projects. When you take the exam, assume that every effort has been 
made by the project manager to uncover all requirements to the degree that can be known, and that those requirements are 
ranked by order of importance. 

Agile and hybrid approaches are often used when the exact requirements are unknown. A) 


Example You may be building something your organization has not done before, such as creating a 
customer (or patient) self-service portal that allows each customer to manage their own account. In this case: 


Agile 

Focus 

+ You may not know what the most popular functions will be or the exact extent of the scope. 

* You may allow customers to change their own name and address fields and enrolled services, but what about deleting 
their accounts? 


* Do all the key stakeholders agree about what features should and should not be included in a self-service portal? 


Additional requirements are often uncovered after some use of the product or service as well. 
+ After launching the self-service portal, you might learn that a large percent of customers access it on a mobile device, 
but the portal was optimized for a PC. 


* You might also discover a competitor $ portal features a “refer-a-fr iend” option that offers rewards, and you may want 
to create a similar program. 


A project like this, where the scope is not well defined, may be best completed using an agile or hybrid project. You 
could, for example, use questionnaires and surveys to find out what the most important and first features of the product 
should be. You could create committed focus groups so that as the first release is rolled out you have customers willing to 
use it and help you further develop the features to come next, and so on, until the product is mature and periodic upgrades 
are all that are needed. 


Think About It. Often, scope and priorities change. Hie longer the project, the more likely the scope will 
change because of changes in the market, technology, or organization. Take a moment to think about the patient 
= portal example in terms of the ECO’s Business Environment domain. Here are some examples: 


e Plan and manage project compliance (task 1) How often do the regulations change? What type of SME (subject 
matter expert) is needed to ensure compliance, and where will those SMEs come from? Outside the United States, 
what are the compliance requirements and how will you ensure your site complies with them? 

e Support organizational change (task 4) How will you ensure that everyone within the clinic understands the 
product vision, is trained on using it but also embraces the changes to come within the organization and for the 


customer (patient). This type of supporting organizational change is so significant and often so big that it could be 
done as a sub-project or a “release” of its own. 


166 


SEVEN Scope 


Resolving Conflicting Requirements 
It is often difficult to prioritize conflicting requirements. 


Example Consider the following examples from an organization that is embarking on a project to improve their 
product development processes: 


+ What if the engineering department wants the project to focus on decreasing defects while the accounting department 
wants the project to focus on lowering costs? Can both needs be met? 


+ What if the engineering department is the primary stakeholder or even the sponsor of the project? Should that 
department s'needs outweigh the needs of the accounting department? 


+ What if the needs of the engineering department negatively impact the accounting department? 


Some issues cannot be resolved by the project manager and team. These require sponsor or other management 
intervention. However, there are some standard guidelines for balancing competing requirements. For the exam, keep in 
mind that competing requirements can be resolved by accepting those that best comply with the: 

+ Business case * Scope statement 


e Project charter + Known project constraints 


Here are additional considerations: 


* Reject a stakeholders request to do or add something that is not related to the reason the project was initiated. It 
cannot deliver project benefits if it is not related to the project charter. 


+ If a requirement is related to the reason the project was initiated but does not fall within the project charter, this 
request should also be rejected. The project manager could encourage submission of a new project request instead. 


+ Suggested changes to the project charter must be brought to the sponsor for approval. Typically a project charter does 
not change beyond the initiation and visioning stages of the project. 


When considering constraints, if the most important constraint is schedule, then: 


+ New requirements that would delay the schedule will not likely be accepted. On an agile project, of course, they could 
be added to the backlog and other requirements deprioritized to another project. An agile project backlog does not 


have to be completed at the end of a project because some features could be deferred to another, future project. 


+ New requirements that compress the schedule or at least do not delay the schedule (without serious impact to other 


project constraints) will likely be accepted. 


Whether a project is plan-driven, agile, or hybrid, requests that do not fall within these guidelines could become part 


of a future project instead. 
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7.1 Exercise 

This exercise describes some of the key actions involved in balancing stakeholder requirements. It goes beyond the 
Collect Requirements process and looks at this effort throughout the project. Spend time thinking about balancing 
requirements. This exercise will help you determine whether you really understand the process. 


In your Exercise Notebook, create a table like the one below (you do not need to write down every action, simply 
write down the number). Read through each action and place a checkmark in the “Know” column ifyou understand 
the action described. Put a checkmark in the “Do” if you actually apply the action in the real world. After you’ve 
gone through the list, make sure you return to the actions without two checkmarks and spend time working 
through them in a way that makes them real to you so you can answer related questions on the exam. 


Action Know Do 
1. Identify all stakeholders; understand their needs, wants, assumptions, and expectations 
for the project. 


2. Get requirements as clear and complete as appropriate for the selected development 
approach before starting project work. 


3. Use information about stakeholders and their requirements to resolve competing 
requirements while work is being done on the project. 


4. Look for competing interests during project planning; don’t wait for competing 
interests to show up during execution. 


5. Look for possible options to resolve competing interests and alternative ways of 
completing project activities. This may involve using techniques such as brainstorming, 
schedule compression, reestimating, and other practices. 


6. Resolve competing requirements from stakeholders based on how the requirements 
affect the project. 


7. Give priority to the customer. (For the exam, know that if any needs conflict with 
those of the customer, the customer’s needs normally take precedence.) 


8. Use quality management to support the project’s satisfaction of the problems or 
opportunities for which it was undertaken. 


9. Deal with problems and conflicts as soon as they arise through the use of consensus 
building, problem-solving, and conflict management techniques. 


10. Say no to some of the competing interests. (For the exam, assume the project manager 
has the authority to say no when necessary to protect the project.) 


11. Fix the project when the project metrics start to deviate from the requirements, rather 
than changing the requirements to meet the results of the project. 


12. Work toward fair resolutions to disputes—solutions that consider the interests of all 
stakeholders as well as the needs of the project. 


13. Hold meetings, interviews, and discussions to facilitate the resolution of 
competing requirements. 


14. Call on management to help resolve competing interests when the project manager 
and team cannot come up with a fair and equitable solution. 


15. Use negotiation techniques to resolve conflicts between stakeholders. 
16. Plan and implement effective communication. 


17. Gather, assess, and integrate information into the project. 
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Verifying Requirements 

It is important for plan-driven and agile projects alike to verify requirements at every opportunity. This often entails 
meeting with the customer to clarify requirements that are not clear and discuss requirements that have already been 
elicited in order to make sure they are well understood. There should be a common understanding about requirements 
between the customer and team. Often prototypes are useful to show the customer and ensure the requirements are well 
understood before building an increment of the product. 


Iteration Reviews (Post-iteration Product Demos) Projects that use agile and hybrid approaches A) 
frequently demonstrate completed increments. Sometimes stakeholders are not interested in early increments Fa d 
where there is not yet much visible functionality. But this is exactly when teams most want feedback. Getting fom 
stakeholders involved in early reviews is important because it stimulates their ability to see and articulate what 

their requirements really are. The project manager and the team must explain how important this early feedback is to get 
the design and features right before change becomes more costly. 

Project managers on agile and hybrid projects should explain the cost of change (see “Stakeholders” chapter) to 
stakeholders. Teams want to discuss changes when the product design is still in development and the cost of change is 
relatively low. This requires the team to have courage to demonstrate incomplete solutions that may face criticism and the 
business to have trust and imagination into how the system may look in order to provide feedback as soon as possible. 


Requirements Documentation and Other Artifacts 
After requirements have been elicited and analyzed, verified, and prioritized, documentation can be completed. 


Requirements documentation on predictive projects is typically more formal than on adaptive projects which use 
lightweight techniques like hand-drawn diagrams. Imagine eliciting requirements from hundreds of people. Can you see 
how documenting those requirements would be useful? This documentation is an output of the Collect Requirements 
process and helps to ensure all requirements are clear and unambiguous. 


Acceptance Criteria Requirements documentation can contain many types of information, but one thing that must be 
included is acceptance criteria. To avoid having requirements that could easily be misunderstood, a great question to ask 
stakeholders is, “How will we know if the work we do will meet this requirement?” Not only is this a good way to make sure 
you understand the stakeholder s requirement, but it also helps to ensure the work being done will be acceptable. 


Definition of Done Most often associated with agile projects, this is beneficial on any type of project. Teams _ 


specify a “definition of done" for each product component at the user story and the release levels, as well as at ( A } 
the final product deliverable level. For example, imagine a case study where we are building a house. Because of 
funding is only going to be available at different intervals, the house has to be built using an agile life cycle. The Focus 


following examples describe when deliverables for the house are “done,” and the final product is the 
completed house: 


e User story level (The story is "Concrete Curing completed”) "Curing completed” requires first that the foundation 
is laid, and the concrete has been poured. The “Concreate Curing Completed” is done after 7 days which is sufficient 
to allow the weight of walking on it (24-48 hours) but also the weight of construction vehicles (7 days). 


e Release level (“Foundation complete”) “Foundation complete” is “done” when the foundation is laid, concrete 
curing completed, tests completed, inspection completed, shown to homebuilder, response to homebuilder feedback 
is completed, and homebuilder has approved/signed off on it. 


+ Final product deliverable (The “dream house” project is completed!) “Dream house” is "done” when all high- and 
medium-level priorities are complete according to their individual definitions of done, all inspections and inspection 
sign-offs are complete. The buyer has moved in and has successfully used all mechanicals in everyday usage for two 
months. They have completed a customer satisfaction survey giving at least a 4 on a 1-5 scale. (Note that low-level 
priority items for a home build might include finished landscaping or a planned finished basement. The buyer may 
take ownership with these items remaining on a backlog.) 


Relationship to Validate Scope Requirements must be described in such a way that associated deliverables can be tested 
or measured for the Validate Scope process to confirm that the deliverables are acceptable. The level of documentation 
detail is iterated until each requirement satisfies the criteria of being clear, complete, and measurable, and acceptance 
criteria are established. 
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Requirements Traceability Matrix Have you ever worked on a project in which some requirements got lost in the 
details? It can be difficult to remember where a requirement came from, what its significance is to the project, or what other 
requirements it is related to. Losing track of requirement details can result in a project objective being missed. The 
requirements traceability matrix is a form of requirements documentation that helps link requirements to the objectives 
and to other requirements to ensure the strategic goals are accomplished. The matrix is used throughout the project in 
analyzing proposed changes to project or product scope. An example of a requirements traceability matrix is shown in 
figure 7.8. 

Information like requirement identification numbers, the source of each requirement, who is assigned to manage the 
requirement, and the status of the requirement should be documented in the requirements traceability matrix. For large 
projects, however, including all this information in the matrix would make it cumbersome and difficult to use. Another 
option is to store this data in a separate repository, preserving the matrix as an easy-to-reference tool. For the exam, simply 
understand that the requirements traceability matrix links requirements to objectives and/or other requirements, and that 
the requirements attributes, such as identification numbers, source, and status, also need to be documented. 

Assigning responsibility for certain requirements management is similar to the concept of assigning risk owners, 
described in the “Risks and Issues” chapter. Assigning team members to manage certain requirements helps to ensure the 
objectives are met and also helps free up the project manager’ s time. Requirement ownership is another type of work team 
members may do on a project in addition to their work to produce the product. If a business analyst is on the project team, 
they would manage requirements. 
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FIGURE7.8 Requirements traceability matrix 
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The Define Scope process is concerned with what specifically is and is not included in 


the project and its deliverables. This process uses the requirements 


just discussed as resulting from the “Collect Requirements” process. Other artifacts to 
work with are the project charter, scope management plan, assumption log, and the 


risk register. 


Predictive Project Management and Scope Defintion 
This is how scope definition plays out in predictive environments: 


+ Everything known at a high level about scope was documented in the 


project charter. 


+ Many more details about scope are uncovered and docume: 


SEVER 


Scope 


documentation 


nted during the 


Collect Requirements process. At this point the requirements determination is sufficient to finalize the scope 


definition for the project management plan. 


* Once the project management plan (with this definition in 
will be subject to the Integrated Change Control process. 


Adaptive Scope Definition 


it) has been approved there may be changes to it but they 


How would you define scope in adaptive environments? Let’s look at this process from an agile perspective. A 


good reason to use agile is that scope is emerging, so scope will be 


Agile Requirements and Scope Definition 


relatively flexible. Agile 
Focus 


In adaptive environments, requirements and scope definitions are emerging through much of the project. On agile projects 


scope is defined with progressive elaboration; first at the chart 


ering and visioning levels in Initiation, and then with the 


creation of a high-level backlog and a release plan. Agile teams then decompose product feature requirements from the 
high-level backlog by progressively elaborating feature requirement details and “slicing,” or decomposing, high-level stories 
into smaller, more manageable pieces of work, much like creating and decomposing the work packages of a WBS in a 
predictive environment. Decomposition is discussed in the Agile Scope Decomposition section of this chapter. 


® Visioning and chartering The value and 
benefits of the product of the project is 
succinctly described during visioning (in 
feasibility—not shown here). In chartering, 
project objectives are documented. 


_ Initiation Release Planning 
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FIGURE 7.9 Defining scope in agile 
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Flexible Scope Definition in Favor of Time and Cost 


Timeboxes allow agile teams to define and manage a flexible scope to achieve the highest priority, best-quality product 
within a fixed cost and a fixed timeframe. You can think of scope on an agile project then to be very flexible while time and 
cost are more fixed. The highest priority items are achieved within the time given for the project. 


Product Analysis As a Scope-defining Method 
As noted at the beginning of this section, part of defining scope is determining what the deliverables of the project are. 


Product analysis is a method of analyzing the objectives and description of the product as stated by the customer or 
sponsor. That information is then used to define tangible deliverables. The work of product analysis may entail analyzing 
the product description and stated requirements, or using techniques such as systems engineering, value analysis, or 
value engineering. 

Product analysis allows the project manager to make sure the product and project scope are understood and accurate. 
For the exam, realize you may need to determine and define deliverables as part of the project, rather than receiving a 
complete list from the customer. 


Artifacts of Defining Scope 

Project artifacts resulting from the Define Scope process for a plan-driven project include the project scope statement and 
updates to other project artifacts like the requirements documentation, a requirements traceability matrix if one will be 
used, and updates to the stakeholder register and the assumption log. 


Project Scope Statement 


This is the primary artifact of Define Scope. This document in effect says, “Here is what we will do on this project,” or “Here 


is the approved project and product or service scope for this project.” The project manager and the team will have had 
many discussions with stakeholders. Many things that are not in the project will have been discussed and not accepted 


because they were not in the charter and did not belong to the project. So in the project scope statement, the project 
manager must also be sure to identify what is not in the project. They should also clarify areas where they have learned 
there are elements of the scope that could be easily misunderstood. 

The project scope statement in predictive environments typically includes the following: 

* Product scope 

* Project scope (including descriptions of project management components) 

+ List of product deliverables 

+ Acceptance criteria 

+ What is not part of the project 


+ Assumptions and constraints 


In agile there may or may not be a scope definition in the form of a scope statement. There will definitely 
be components of scope as described in the Adaptive Scope Definition section of this chapter. Additionally, | 


agile teams decompose large or complex stories into smaller, more manageable stories. These smaller “more 
manageable stories” are analogous to work packages of a WBS on a plan-driven project. What this means is = 

they've been broken down so that they can be more easily estimated for time, cost, and other resource needs and assigned 
to team members to be built. Completed stories prioritized to be part of a release are then integrated together to become a 


working increment of the product that can be released to the customer. 
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Create WBS (Decompose Scope 


In planning for predictive practices, scope decomposition consists of creating a WBS 
and WBS dictionary. The scope definition consisting of the scope statement, WBS, 
and WBS dictionary make up the project’ scope baseline, so there is no questioning 
the need for all three of these components. 

The following sections about the work breakdown structure (WBS), WBS 
dictionary, and the scope baseline are largely from the Process Groups model’s 
perspective. We will discuss agile scope decomposition following these sections. 


The Work Breakdown Structure (WBS) 

What is a WBS? Understanding and using this tool is essential for successful projects 
using a traditional approach, and for passing the exam. Start by testing your 
current understanding. 


7.2 Exercise 


What does a WBS contain and what is its value as part of the scope baseline? Write the answer in your 
Exercise Notebook. 


Answer 


The WBS is a visual, organizational tool (like an information radiator!) showing all the scope on a project, broken 
down into manageable deliverables called work packages. It helps ensure that no deliverables are missed. It is also 
a communication tool since it gives an image of what is included in the project. 


Here are a few additional answers that may further define a WBS and its value to the project. 


+ The construction of a WBS graphically provides a structured vision for a project and helps to ensure that 
nothing, including deliverables, is forgotten. 


+ A WBS is created with input from the team and stakeholders. Involving the team and stakeholders helps gain 
buy-in, and increased buy-in leads to improved performance. 


+ The process of creating a WBS allows the team to go through a project in their minds and thus improves 
project plans. The execution of a project is typically easier and less risky as a result. 


+ Being involved in the creation of a WBS helps people better understand a project. It also makes a project seem 


more achievable. 


+ A WBS shows a complete hierarchy of a project, making it easier to see how one deliverable relates to another. 
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Review the WBS example in figure 7.10. 


Requirement Design Installed hardware Test Trained Turnover 
document document and software reports staff documentation 
CO ee | 


Interview 42° Signed E Operational Software Database Hardware Unit test System User test Turnover Warranty 


report ist document document document hardware files files test report report test report report report fixes 


1 _ —1 1 


Installed Interface Program 
hardware files files 


FIGURE 7.10 4 (summary level) WBS for a hardware/software creation and installation project 


Decomposition, of course, needs to be tailored to the project. Typically the project name goes at the top of a WBS and 
the next level is the development life cycle. Subsequent levels break the project into deliverables, which are then broken 
down in succession until decomposition gets to the work package level (described next). 

Did you know that a WBS allows you to break down a seemingly overwhelming project into pieces you can plan, 
organize, manage, and control? The creation of a WBS is an effort to decompose deliverables into the smaller component 
deliverables (work packages). Decomposition can be done using a top-down approach (starting with the high-level pieces 
of a project), a bottom-up approach (starting at the work package level), or by following organizational and industry 
guidelines or templates. 

For the exam, know that on a WBS, work refers not to an activity, but to the work products that result from an activity 
or group of activities. Work packages are things (deliverables, product) rather than actions (activities). The complete 
product scope as well as the project scope (including project management activities) are included. 


WBS Guidelines 


Every WBS is unique, and every project manager will create a WBS in their own way. For the exam, here are some guidelines 
that every project manager should follow: 


+ The project manager creates the WBS using input from the team and other stakeholders. 
+ Each level of a WBS is a breakdown of the previous level. 


+ The entire project should be included in the highest levels of the WBS. Not every level needs to be broken down 
further but those resulting in work packages must be broken down to the work package level. 


+ A WBS includes only project deliverables that are requirements. Deliverables not included in the WBS are not part of 
the project 


During planning, the project management team and subject matter experts break down the scope definition until the 
work package levels are reached. This occurs when the deliverables: 


e Can be realistically and confidently estimated (including the activities, duration, and cost associated with them) 
* Can be logically assigned to a distinct resource or resources 

* Can be completed relatively quickly 

* Can be completed without interruption and without the need for more information 

* May be outsourced with minimal or no disruption to the internal team. 


The levels in the WBS are often numbered for ease of reference. WBS software does this automatically and there are 


different numbering systems you can use. 


Figure 7.11 provides an example. 
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On the exam you may see the term “planning package” or “control account,” as seen in the figure. 


| 1111 | 142 [iiz ESEE] 2131 2211 


EANA ATEA 1421.1 2421.1 2.1212 22.12.14 22.122 2212.3 2211.1 2221.1 


a Control account 
Work packages 


FIGURE 7.11 Sample WBS numbering system 


Control accounts, which may include one or more planning packages, allow you to collectively manage and control 
costs, schedule, and scope at a higher level than the work package. Each work package in the WBS is assigned to only one 
control account. 


The WBS and Schedule Planning 

As planning progresses the team breaks down the work packages from the WBS into the schedule activities that are required 
to produce the work packages. The activities and their data are typically entered into a Gantt chart of traditional project 
management software. The data can help to create the project schedule. Often project management software can also 
generate a network diagram from the Gantt chart data. In the following list you can see from some of the basic activity data 
how planning scope is related to planning schedule, cost, resources, and other constraints: 


è Name (of work package) ® Start date 
* Duration è Finish date (typically driven by duration) 
è Dependencies (what must be done before this work © Resource assigned 

package?) 


Scope Statement, WBS, and WBS dictionary i 
The team uses these three plan components to help to define the activities required to produce the deliverables. The WBS 
dictionary is described in the next section of this chapter, and the Define Activities process is described in the 


“Schedule” chapter. 


How Work Packages Are Defined 

Just how project scope is broken down into work packages is tailored to the project. Historically the guidelines have been 
that on small projects a WBS is often broken down into work packages that take between 4 and 40 hours to complete. 
Medium-sized projects may start with work packages of 8 to 80 hours in work, while large projects may start with packages 
of300 hours of work. While we include them here in case you run into them on the exam, these historical examples are not 
as likely to appear in questions as they once were. This practice has decreased in favor of a subjective-level decision by the 
team as to “what makes sense” in terms of being able to estimate, resource, and build a work package. Since the project is 
planned iteratively regardless of the approach, work package definitions can be iteratively refined. 


The WBS As Organizational Process Asset 
If your company works on many similar projects, the WBS from one project may be used as the basis for another. Expect 
for exam purposes that the PMO collects and shares WBS examples, encouraging the creation of templates. 


Do you really understand the WBS and its importance to planning and managing scope in predictive environments? 
Try the next exercise. If you miss many of the answers, then this is a gap area for continued review before the exam. 
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7.3 Exercise 
Test yourself! What are the benefits of a WBS? Write the answers in your Exercise Notebook. 


Answer 
The following are benefits of using a WBS: 


Gives a picture of the entire project's scope 

Helps people better understand the project 

Provides the team with an understanding of how deliverables fit into the overall plan 
Gives team members an indication of the impact of their work on the project as a whole 
Facilitates communication and cooperation for the project team and other stakeholders 
Helps manage stakeholder expectations regarding deliverables 

Helps identify risks 

Helps prevent work from slipping through the cracks 

Helps prevent unnecessary changes 


Focuses the team’s experience on what needs to be done, resulting in increased quality and a project that is 
easier to manage 


Provides a basis for estimating resources, costs, and schedules 
Provides proof of the need for resources, funds, and schedules 
Helps with planning control efforts 


Helps in establishing deliverable acceptance criteria 


Gets team buy-in and facilitates team building 


A WBS is a foundational component of project 


management. Almost everything that occurs in planning we 
revolves around the WBS. Pocuroment COTO: 
We have already mentioned the relationship of scope management list 
planning for cost, schedule, and resources. Figure 7.12 
illustrates how many other project planning components Risk ee 
rely on the WBS. Following are some examples of how the management eS a7 eni 
WBS facilities planning with project constraints: 
+ During project selection and during initiation, costs Quality K á Pa N 
and the schedule are estimated at a very high leveland management Z Resources 
for the project as a whole. During planning, though, Va 
costs and the schedule are estimated at the work et 
package or activity level. Budgeting Scheduling Estimating 


A WBS can help a project manager and team identify 
more risks by examining a project at the work FIGURE 7.12 Much planning revolves around the WBS 
package level. 


+ Resource planning and management are aided by the WBS. Work packages are assigned to resources by work package 


and activity. 


Think ahead for a moment to the project control aspect of having a WBS. The following exercise will help you review 


how the WBS is used beyond planning to also control the project as the team is building the product. 
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7.4 Exercise 

What do you do with a WBS during executing and controlling the project? The WBS is created and used in planning 
but the exam also tests your knowledge of how it is used throughout the rest of the project. So, take some time to 
really think about this question. Write the answers in your Exercise Notebook. 


Answer 
When completed, the WBS can be used any time the project scope needs to be evaluated. You may have thought of 
other things, but some examples follow. 


+ Scope-related change requests A project manager can use the WBS, along with the project scope statement, 
to determine if a change request is within the approved project scope. 


+ Impacts of change The project manager and team can use the WBS as part of the integrated change control 
process to evaluate impacts of requested changes to project scope. 


e Controlling scope creep Project managers can control scope creep by using the WBS to reinforce what work 
is to be done. (“Scope creep” refers to scope increasing without appropriate change control processes.) 


+ Communications The WBS is a communications tool when discussing the project among the team or with 
other stakeholders (e.g., the sponsor, the customer). 


+ Team orientation The WBS can facilitate new team members understanding their project roles. 


TRICKS Now, would you like to get more exam questions right? First, know that the exam may use the term 

OF THE “deconstruction” as well as “decomposition.” Both terms mean the same thing. Second, many people confuse 

tA the terms “WBS” and “decomposition.” They are related but there is a distinction. The best way to think of 
decomposition is that decomposition is what you are doing, and a WBS is the method to do it, and it is also the 


artifact that results from the effort. In other words, you decompose a project and manage its scope and other constraints 
| using a WBS. 


WBS Dictionary 
Think about how a work package is identified in a WBS. It is usually described using only one or two words. But assigning 
a deliverable with such a brief description to a team member allows for too much variation (which itself could cause scope 
creep). The WBS dictionary is the documentation providing details needed to build each work package. It also lists 
acceptance criteria for each deliverable, ensuring the resulting work matches what is needed. The project manager and 
team can use a WBS dictionary to further understand the work that needs to be done, and to prevent scope creep before 
work even starts rather than dealing with scope creep while the work is being done. 

The WBS dictionary is an output of the Create WBS process. It may be used as part of a work authorization system, 
which informs team members when their work package is going to start. You can also use it to clarify a stakeholders 
understanding of effort needed for a work package. Figure 7.13 is an example of a WBS dictionary. A WBS dictionary can 


include descriptions of: 
* Schedule milestones + Interdependencies 
+ Acceptance criteria * Other work package information 


* Durations 
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Control Account Work Package Date of Update Responsible 
ID# Name/Number Organization/Individual 


Work Package Deliverable Description: 
Work Involved to Produce Deliverable: 


Acceptance Criteria (How to know if the deliverable/work is acceptable): 
Assumptions and Constraints: 
Quality Metrics: 


Technical Source Document: 


Risks: 
Resources Assigned: 


Duration: 


Schedule Milestones: 


Cost: 
Due Date: 


Intedependencies (before this work package): 
Interdependencies (after this work package): 


Approved by: Date: 
FIGURE 7.13 WBS dictionary 


Note: Some of the entries in a WBS dictionary, such as durations and interdependencies, may be filled in during 
planning iterations rather than when the WBS and WBS Dictionary are first drafted. Interdependencies, for example, are 
best defined and understood as a result of doing a network diagram, which is part of schedule planning. 


Scope Baseline 
In predictive environments the scope baseline is a set of artifacts that make up part of the project management plan and 
includes the project scope statement, the WBS, and WBS dictionary. 

The scope baseline is approved at the end of planning and before the work of building the product begins. Then, as 
the work on the project is being done, the project manager reviews how the project is progressing and compares that data 
to the baseline by answering the following questions: 


* What scope has been completed on the project? 


+ Does it match what is defined in the WBS, WBS dictionary, and project scope statement? 
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Changes to the Scope Baseline __ 
If scope is needed that is not in the baseline: 


+ A change has to be formally approved through the Integrated Change Control process. 

+ Anew item (or items) needs to be added to the WBS, WBS dictionary, and project scope statement to reflect 
the change. 

* The updated documentation becomes the projects new scope baseline. 

e Other artifact components that are affected by the scope change need to be updated, including (most commonly) 
requirements documentation and the assumption log. 


Performance Measurement 
Measurements of project success include whether the project has met all the requirements, including the scope baseline. It 
is essential to use these tools of project management in the real world. Aside from their use in achieving project success, 


you need to feel comfortable with them for the exam. 


Agile Scope Decomposition 
Now let’s talk about decomposing project scope from an agile perspective. Ibis is worth repeating from the 
Adaptive Scope Definition section of this chapter: 


g 


+ In agile, product scope is defined at a high-level during project visioning and chartering. 
+ After this, a high-level product backlog is created, and release planning is started. 


+ From that high-level product backlog, product features are decomposed into smaller stories that can be estimated, 
assigned resources and built. 


Notice that this is in essence the principle of progressive elaboration. Early on the project manager and the team 
gather high-level scope definition details. From there product features are progressively decomposed into these smaller 
stories through story writing workshops and “slicing” (decomposing) stories. 


Requirements Identification and Decomposition Progression 
Think about it. The following is agile scope decomposition, illustrated. Figure 7.14 shows levels of agile 
£ requirements. Following the figure, the sections of the illustration (numbered for convenience) are explained in 
a greater detail. Then, walk through an agile project in your mind, using the health clinic client portal case as 
an example. 


Details 
Just In Time 


Business Rules 


Oo soyi | MepePianeales's 
Story 2 kaii 
Siny 3 Siada 


Tasks 


1 2 3 4... 


Just In Time Requirements Breakdown...More Definition 


FIGURE 7.14 Levels of agile requirements 
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1. High-level Requirements or objectives are identified at the beginning of the project. Although agile practitioners 
accept that scope is emerging, they still make the effort to uncover as many requirements as possible from the start. 
It is unlikely you will see the word epic on the exam but in case you do, know that some agile practitioners use it to 
describe the biggest of requirements (or stories). Epics are too large and complicated to build without 
decomposition. 

2. Medium Features are created from large and complex, high-level requirements. The level of decomposition here 
is called “medium” in the figure but notice that we are just using relative terms. There is no exact definition of 
“high-level” versus “medium,” etc. 

3. Small Medium-level requirements are broken into smaller stories. 


4. Details Each story needs to be broken further by various types of requirements, some of which are depicted in 
figure 7.14. The breakdown is described as just in time because agile teams wait for the last responsible moment to 
make sure they have all the details to build a story. The last responsible moment is the moment at which story 
decomposition has reached its logical conclusion and the most information is available about what needs to be 
done to build a story. 


Agile Decomposition: Health Clinic Client Portal 


First and foremost, agile product feature prioritization and decomposition is value-based, always done from the standpoint 
of what stakeholders find most valuable. 

e Release map scope decomposition level Review figure 7.2 on page 159 of the patient client portal project 
roadmap example. This will make it easier to walk through the project in your mind. The roadmap for the patient client 
portal project is shown in three releases. These are the high-level requirements (or epics). 

+ Product backlog decomposition level Review figure 7.3 on page 160: This is the product backlog. Listed in it is 
likely to be a combination of high- to medium-level features, which must be decomposed further into smaller stories. 
The “manage web accounts” set of features shown in the product roadmap for Release 1 could be comprised of Pl 
(manage appointments), P2 (change personal data and preferences), and maybe other features in this backlog. 


+ Story decomposition level A given feature is usually sliced (decomposed) into two or more stories; as this is done 
more details about the individual stories emerge. Stories can be compound, complex, or both. Figures 7.15 and 7.16 
gives examples of each in the patient portal case study. 
>/ A compound story has multiple independent stories within it 


>/ A complex story is a big story that has to be broken down to decrease its complexity 


Detailed decomposition level At this level the team needs to have detailed story information established, like 
definitions for business rules, unit tests, acceptance tests, and tasks to build the story. 


Patient website Patient website 


web account 


FIGURE 7.15 Slicing a compound story FIGURE 7.16 Slicing a complex story 
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Other Agile Scope Decomposition Opportunities 

In addition to product and project visioning, product roadmap, release, and iteration planning opportunities for scope 
decomposition on agile projects, agile teams are aware of the fact that throughout the project, opportunities emerge for 
better and different ways of breaking down requirements so the related stories are easier to build. Here are a few examples: 


Example from the daily standup At a daily standup meeting for the patient client portal project, a team member 
mentions they are having problems with regulation C because its technical requirements in the program interfere with 
the technical requirements of regulation A. After the meeting, the project manager gets the team member in touch 
with a systems architect they know has experience in this area to help simplify the programing for these regulations. 


Example from a “design, build, test, accept, release” model These steps describe the common iterative cycle 
process that continues throughout the project. At any time during this process opportunities for improvement in 
story decomposition can emerge. For example, let’s say during the build step two team members are practicing paired 
programming. (This means two programmers sit together and take turns with one person programming while the 
other watches.) What if the observing programmer on the “manage account” story in figure 7.17 suddenly realizes 
that the stories for this feature can be broken down and built in a different way that results in a better, simpler design? 
Although perhaps invisible to the end user, the product has just been improved. 


Methods for Agile Story Decomposition 


You probably know intuitively that there can be many methods of breaking down features and functions of a product, but 
you may not be aware of these less obvious methods. Here is a list of some common story breakdown methods. 


Process-based breakdown The “manage account” story in figure 7.17 shows a process-based breakdown. The 
process described as “Manage account" is shown to have three sub-processes associated with it (although there are 
more than the sub-processes shown in this simple example). 


CRUD (Create, Read, Update, Delete) This acronym stands for the list of things a programmer wants to allow a 
user to do with data. See the illustration in figure 7.17. We provide this example to help you remember the term 
CRUD, which may be used on the exam. You will not need to know more than this about this method. 

Business rule-based breakdown An example of a business rules breakdown might sound like this: “There are 
many ways for a patient to pay a bill. On the website we only accept the use of VISA, Mastercard, bank information for 
automatic withdrawals (if a payment plan is needed), and PayPal. For this example, the team will break down stories 
based on what it takes to build in this functionality. 

User or platform-based breakdown An example of the need for this type of breakdown is “We have to make this 
product easily usable on desktop PCs, laptops, tablets, and mobile devices.” 

Acceptance test breakdown An example of this is employing acceptance test-driven development (ATDD). With 
ATDD, acceptance tests are built before the story is built and then the story is built to pass the test. 


MoSCoW analysis This is a breakdown method of higher-level requirements at the release map and product 
(feature) backlog levels. MoSCoW stands for “Must have, Should have, Could have, and Would like to have,” and is a 
prioritization scheme for selecting features and functionality. 


Scope SEVEN 


Figure 7.17 shows how “manage account” may be broken down using CRUD. Notice that “D” is not included since 
the clinic will not want a patient to be able to delete their own account. 


Original: 
Manage account 
(login, password, 


Create contact us) 
Read 
Asa 
date 
up patient Asa 
patient Asa 
Delete | (want to) patient 
create n\y | (want to) 
site account read w\y site | (want to) 
account page update w\y 
password 
FIGURE 7.17 CRUD functional decomposition 


Validate and Control Scope 


Many people are confused about what it means to validate scope. If you correctly un- 
derstand scope control and validation from the perspective of the Process Groups 
model, you can get more questions right on the exam. According to the Process 

Groups model, validate and control scope are two distinct processes, but let’s review 
the process of validating scope together with the process of controlling scope so you 
understand them holistically and are ready for related exam questions. 


TRICKS First understand where in the project management process scope is 

(0) validated. Many people think scope validation means confirming the 

validity and appropriateness of the scope definition during project 

planning. The Validate Scope process actually involves frequent planned 

| meetings with the customer or sponsor to inspect and gain approval of deliverables 


during project control. That’s a big difference, isn’t it? 


Validate Scope 

This is ideally the result of all project work—accepted deliverables! Validate Scope means taking already verified results to 
the customer. The customer will either accept deliverables or make change requests. The successful process culminates in 
the customer signing off on the results. This process is repeated throughout the project as interim deliverables are completed 
until the end of the project when the customer signs-off on (or validates) the final, delivered product—or on agile projects, 
the minimal viable product. 


Control Scope 

The project manager and team control scope throughout the project—before, in concert with, and after the validate scope 
process. This, then, for the project manager is about monitoring progress, looking for ways to remove impediments to the 
team who are completing the scope in the allotted time and cost. This is how the project manager can help the team ensure 
that Control Quality will bring about expected, verified results, and the Validate Scope process can happen without 
difficulty. It involves measuring and assessing work performance data against the scope baseline and managing scope 
baseline changes. 
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at are the inputs to validate scope? Here’s an exercise to look at the inputs to this process. 


Exercise 


In your Exercise Notebook, write the answer to this question: “What do I need before I can validate scope?” 


Answer 


Verified deliverables Validate Scope is intimately tied to Control Quality. Completed work must be checked 
before meeting with the customer. The deliverables are verified in Control Quality. _ 


Scope baseline This is needed (from the project management plan) for comparison. It’s helpful to have the 
approved scope when meeting with the customer. 


Scope management plan This plan shows and plans for gaining formal acceptance of approved deliverables 
(described in the scope baseline). 


Requirements management plan and requirements traceability matrix The project manager exchanges 
information about the requirements and shows the customer how they have been validated. Comparing the 
requirements to results will help to determine if any action or change is needed. 


Work performance data This data from the Direct and Manage Project Work process helps the project 
manager assess how well product deliverables are meeting the requirements. 


Other project documents Quality reports and lessons learned should also be reviewed at the start of this 
process. Quality reports can include information about open or closed issues. Lessons learned can be used to 
improve the process of validating project deliverables. 


Did you notice that we didn’t just list what the project manager needs to do but described how each artifact will 
be used? Whenever you think about the inputs of a process, make sure you can describe them and explain 
where they come from and what they offer to completing the process. Similarly, make sure you understand how 


outputs flow logically from each process. For the exam, this deeper understanding will often give you more 


insight into situational questions, help you distinguish between relevant and extraneous data, and help you select the 


correct answers. As you study, this understanding will spare you the need to memorize lists of terms like those used to 


name inputs, outputs, and tools and techniques. 


& 
© 


Think About It. Did you happen to notice that there are no executing processes in the Process Groups model 


for the project manager for scope? This will be true of schedule and cost processes too, and it is because the team 


is responsible for the executing processes of scope, schedule, and cost. They are building the product (and 


spending the time and money to do so). 


Now try an exercise on the efforts and outputs (artifacts) of these processes. 
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7.6 Exercise 
In your Exercise Notebook, list what you are doing to control and validate scope, and what you have when you’re 
done with the same processes. 


Answer 
What We Have When We Are Done with 
What to Do to Control and Validate Scope Control and Validate Scope 
+ Help the team focus on approved scope; do not + Change requests 
add extras + Accepted deliverables 
+ Help the team build from the top of a * Updates to project artifacts 
prioritized list like a backlog e Work performance information 
+ Collaborate with the team on ensuring a + Possible updates to processes and procedures 


common understanding of scope 

+ Remove impediments for the team 

+ Gather and analyze work performance data 

* Work on continuous improvement of processes 
and product quality 

* Compare the deliverables to the requirements 
to make sure they meet stakeholder needs. 


Methods for Control and Validate Scope 
Traditional methods for controlling and validating scope in predictive environments are based on observation and analysis. 
They include: 


Inspection Product inspection is a routine part of controlling and verifying scope internally before validating scope with 
the customer and is in fact part of Control Quality. 


Data Analysis is used in Control Scope. It includes variance analysis, which is comparing the scope baseline to actual 
project results to determine if variances are within acceptable limits. Related to this over a longer period of time is trend 
analysis, which helps tell the project manager and team if project performance is improving or worsening. 


Decision Making Based on the data the project manager and team observe and analyze, and inspection of the workings 
of the product, the project manager and team can make decisions, largely based on consensus. Decisions may include how 
to handle issues, work around or fix problems on the spot, and otherwise prepare the product increment in question to 
either go to the customer for validation or remain in development until all issues are resolved. 


Controlling and Validating Scope in an Agile Environment 


On a change-driven project, controlling, verifying, and validating scope happens at the end of each iteration 

as part of the iteration review with the customer. Let’s say the team, in collaboration with the customer, has \ A } 
settled on doing three, two-week iterations, plus a “hardening off’ iteration (to make sure everything is ready f Agile 
for release) before each product release. By the time an MVP is ready for the first product release, the team and Fens 
customer have participated in three or four iteration reviews (if the hardening off iteration is included, and it typically is) 


where the customer has seen the increasingly mature product release before it is delivered to the marketplace. 


Agile Ceremonies (Meetings) Throughout the project and during every iteration the team has daily standup meetings to 
report to each other what they have been working on and have completed, what they will continue working on toward 
completion, and whether there are any impediments to progress. At the end of each iteration the team meets with the 
customer to demo and discuss what they have built, hopefully getting acceptance of that iteration’s work but also taking 
back any customer feedback with which to improve the product increment before delivery. The team follows up each 
iteration review with an iteration retrospective among themselves to further the goal of continuous improvement in all 
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their processes, and particularly in improving the product of the current project. Agile ceremonies are focused on 
controlling and producing project scope. 


Customer-valued Prioritization The role of the product owner is about prioritizing the product backlog according to 
customer priorities. The product owner represents the end users of the product and must bring anyone into the conversation 
who is important to the continuous delivery of the features the end-users (or customers) most value. It is the team’s job 
then to help the product owner maximize that value with advice on technical requirements and risks. These requirements 
and risks are added to the backlog and integrated with the customer requirements for the product. 


Incremental Product Delivery Through frequent product releases the team delivers minimal marketable features 
(MMFs) to the customer until the agreed-upon project backlog is complete. The product backlog usually continues to 
exist across several or many projects, and for some kinds of products, like software, smaller upgrades can be delivered on a 
regular basis as part of product maintenance. 


Artifacts of Control and Validate Scope 
The artifacts of the Control and Validate Scope processes include: 
+ Project management plan and document updates 
+ Work performance information (analyzed work performance data) 


+ Change requests 


For Validate Scope the resulting artifacts also include accepted deliverables. This means approval and formal sign-off 
by the customer, and may happen the first time the team shows a deliverable (product increment) to the customer, or only 


after changes have been made as a result of customer feedback. 
There are a few more aspects to remember about Validate Scope: 


+ It can be done at any point in the project (within a phase) to get formal acceptance of interim deliverables that require 
approval (as part of monitoring and controlling). On agile it is done at the end of each iteration. 


+ Itis done at the end of each project phase to get formal acceptance of interim deliverables. 
+ Itis done at the end of a planned product release in agile. 
+ The difference between the Validate Scope and the Close Project or Phase processes can be a little tricky. 

V The Validate Scope process results in formal acceptance by the customer of deliverables. 

V The Close Project or Phase process is an integration process, to get final acceptance from the customer for 
the project or phase as a whole including not just product scope but project and phase closing activities, like 
indexing and archiving records, for example. 

+ We have already mentioned that Validate Scope and Control Quality are related. The high-level diagram in figure 7.18 
should help you visualize this. 


FIGURE 7.18 Relationship of Validate Scope to Control Quality 
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Although Control Quality is generally done first to verify that the deliverable meets requirements before it is shown 
to the customer, the two processes are similar. Both involve checking for the correctness of work according to requirements. 
The focus is on who is inspecting and approving. 

+ In Control Quality, quality control checks to see if the requirements specified for the deliverables are met. 


+ In Validate Scope, the customer checks and hopefully accepts the deliverables. 


As you take the exam, assume that the project manager is controlling scope to make sure the scope is being completed 
according to the project management plan. There should be a clear definition of and elaboration on scope in the scope 
baseline. Assume proper project management is being done on the project unless the question states otherwise. 

The project manager then has to measure the completed work against the scope baseline, perform data analysis, 
including analyzing any variances, and determine whether the variances are significant enough to warrant changes. If 
necessary, they would submit a change request through the Perform Integrated Change Control process to assess the 
impact the change would have on all aspects of the project. New work performance information may result, along with 
updates to the project management plan and project documents. 

Remember that the Control Scope process is proactive. It includes thinking about where changes to scope may be 
coming from on the project and what can be done to prevent or remove the need for any more changes from that source. 
Properly using project management tools, techniques, and practices will save you from unnecessary problems throughout 
the life of a project. 


Scope: Putting It All Together 


7.7 Exercise 

In our library case study, the project manager who is overseeing the creation of the new community library has 
gathered requirements, but the stakeholders differ on what is needed (or not needed) and on what they would like 
to see in the new library. How might the project manager work to resolve these competing requirements? 


Stakeholder(s) Requirement(s) 


1. City Council A small coffee shop included in the library so people can meet and talk and have a drink/ 
member snack. 


2. Librarian No food or drink should be allowed or encouraged in the library. Spills damage books and 
technology, and costs more for cleaning every night. 


3. Library staff A small kitchen/break room where staff could refrigerate and heat lunches to decrease the 
need to go out for lunch which is costly and takes time. Also beneficial to patrons; 
sometimes a parent wants to heat their baby’s food for story time without leaving the library. 


4. Librarian Against a kitchen because of additional mess and cleaning costs. She thinks the staff can 
simply bring cold sandwiches if they want to bring their lunch. Many employees only work 
part time so don’t take a lunch break. 


5. Mayor Wants everyone who uses the library to login to the system and provide their demographic 
info (name, address, phone, email). They think this data will be useful for increasing voter 
registration and participation. 


6. Citizens group Does not want the library to collect demographic information. They want people to be able 
advocating for to use the library without providing private information. They think the mayor is trying to 
online privacy build a database for campaigning. 


7. IT Security For security, the least amount of information needed should be collected. The system 
Consultant should also require users to view a short security video before they are allowed to use the 
system. 
8. Librarian Some patron information is needed. If a patron checks out a book, and does not return it, 


reminders need to be sent and possibly late fees need to be charged. 
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Here are some sample answers. You may have come up with some other solutions. Just make sure you understand 
our solutions, and that your solutions will help the situation. 


Stakeholder(s) 


1. City Council 
member 


2. Librarian 


3. Library staff 


4. Librarian 


5. Mayor 


6. Citizens group 
advocating for 


online privacy 


7. IT Security 
Consultant 


8. Librarian 


Requirement(s) 


Small coffee shop be included in the library so 
people can meet and talk and have a drink/snack. 


No food or drink should be allowed or encouraged 
in the library. Spills damage books and technology, 


and cost more for cleaning every night. 


A small kitchen/break room; staff could refrigerate 
and heat lunches to decrease the need to go out for 
lunch which is costly and takes time. Beneficial to 
patrons; sometimes a parent wants to heat up baby’s 
food for story time without leaving the library. 
Against a kitchen because of the additional mess and 
cleaning costs. She thinks the staff can simply bring 
cold sandwiches if they want to bring their lunch. 
Many employees only work part time so don’t even 
take a lunch break. 


Would like everyone who uses the library to login 
and provide demographic info (name, address, 
phone, email). The mayor thinks this data will help 
increase voter registration and participation. 


Does not want the library to collect citizen 
information. They want people to be able to use the 
ibrary without providing private information. They 
think the mayor is trying to build a database for 


campaigning. 


For security, the least amount of information needed 
should be collected. The system should also require 
users to view a short security video before they are 


allowed to use the system. 


Some patron information is needed. If a patron 
checks out a book, and does not return it, reminders 
need to be sent and possibly late fees need to be 


charged. 


Ways to resolve 

— Interview architect and construction 
teams; get high-level cost estimate of a 
coffee shop. 


— Send survey to include opinions of 
citizens (potential library patrons). 


—Assist the librarian to research 
estimates for additional cleaning 
costs/damage costs expected. 


— Get bids from coffee shop managers 
who would run the operations. 

— Have a brainstorming session about a 
coffee shop; generate ideas for 
decreasing or eliminating library 
materials damage. 

- Interview architect and construction 
teams; get a high-level estimate of the 
cost of a breakroom with kitchen. 


- Have a workshop with the current 
staff and librarian to talk about the 
pros and cons of this idea. Would the 
staff be willing to clean the kitchen? 


- Analyze current and future staffing 
needs: part time vs. full time. 


- Library software system can be built 
using an agile approach. 


-A backlog of requests will be compiled 
and prioritized at workshops with the 
stakeholders. 


-Aproduct owner could help the 
various stakeholders reach consensus 
on the next requirement meet. 


- MVP could be basic searches for 
materials and the security video. 
Future releases could consider some 


collection of data as the need arises. 


187 


188 


QUICKTEST 


+ Dependencies 


8 Schedule ee 


* Critical path 

+ Milestone 

* Schedule model 

* Schedule Management 


Introduction process 
* Schedule management 
Planning a project schedule and the overall process of schedule management primarily relies on tech- plan 
nical project management skills. How do you manage a project schedule? For this question, many peo- * Precedence diagramming 
ple immediately think about software or a Gantt chart. Yes, software is a valuable tool. It can save time metho LAD) 
a ; ` 5 = P n r * Dependencies 
with scheduling, analyzing what-if scenarios, performing status reporting, and other things. But you Mandatory 
need to understand the details behind the data. seule 
- Discretionary 
This chapter, along with additional exercises on the RMC Resources page =y | - External 
(rmcls.com/rmc-resources), will help you thoroughly understand the process of ‘com/rmeratesources 
planning and managing a project schedule. Historically, exam questions related + Network diagram 


+ Analogous estimating 
* Bottom-up estimating 
i e Parametric estimating 
a | * Single-point estimating 
* Three-point estimating 


a 
to scheduling have required the knowledge of how to draw a network diagram. E 
Agile questions may require you to know how to build a story map. 


Although the process to plan and manage a schedule is straightforward, you (E 
need to know options for developing and compressing a project schedule. A 


project schedule must be realistic before the work to build the product begins. BMG RESOURCES - Triangular distribution 
For the exam, assume you have the authority and responsibility to create a - Beta distribution 
realistic schedule. The exam is written with this assumption although it is not always true in real life. + Activity standard deviation 
e Affinity estimating 
Definitions Related to Plan and Manage Schedule aoea 


* Planning Poker® 


This is some basic estimating and schedule-related vocabulary that will be used in upcoming sections, F ; 
+ Alternative analysis 


where we will cover each concept in more detail. 


+ Reserve analysis 
Contingency reserves 


Dependencies 


Dependencies are logical relationships between activities in a project. The most obvious dependency 


Management reserves 


+ Fist of five 
example is: “Activity A must be completed before activity B can start.” There are other types of 


dependencies, which are covered later in this chapter. 


+ Basis of estimates 
e Critical path method 
e Fast tracking 


Float * Crashing 
Float represents schedule flexibility. Most simply, float is the amount of time an activity can be delayed + Monte Carlo analysis 
without delaying the end date of the project. The definition in practice is a little more involved than * Resource leveling 
this, however. There are several different types of float, which are covered later in this chapter. + Resource smoothing 

+ Agile release planning 
Leads and Lags * Cumulative flow diagram 
A lead may be used to indicate that an activity can start before its predecessor activity is completed. For + Velocity 


example, web page design might be able to start five days before the database design is finished. A lag * Project schedule 
is waiting time inserted between activities. For example, a three-day lag time after pouring concrete is ceMilestone char 
needed before constructing the frame for a building. © erates 

* Schedule baseline 
Critical Path + Reestimating 
The critical path is the shortest path to finishing the project. Projects are complex and have many 

workstreams. The critical path is important because it is the one workstream that has no float (schedule 

flexibility). Since the critical path has no float, any activity along it that is finished late represents a risk 


of the project finishing late. 
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Milestones 

Identified points in the project schedule where particular objectives should be met are called milestones. They are not 
work activities and have no duration but they do fall on certain dates. Initial milestones are documented in the project 
charter. The project manager can also insert milestones as checkpoints to help control the project. A milestone list is a 
project document, often created as an abbreviated view of the schedule. If a milestone in the schedule is reached and any 
of the planned work is not complete, the project is not progressing as planned, i.e., the project is behind schedule. 


Examples A completed design, a company-required checkpoint, a phase gate, or an iteration completion point. 


Schedule Model 
The schedule is always a model of sorts because it is subject to changes based on constant monitoring and controlling of 
the project. The project calendar (or schedule), plus all the associated planning documents is referred to as the schedule 
model. At first it is a working model of the schedule, along with artifacts like the activity attributes and estimates and the 
project schedule network diagram (once it is created). An agile equivalent would include the release map and other release 
planning artifacts, the prioritized backlog plus the current iteration plan. 

As the project schedule is approved the schedule model becomes the current approved version of the schedule along 
with these other schedule-related artifacts. For both agile and plan-driven approaches the project$ historical planned and 
actual results data and analyses inform the current schedule model. 


Schedule Process Overview 


As with all project management processes, you will need to understand how to plan and manage the project schedule from 
several perspectives. The Schedule Management process from the Process Groups model is one way to speak about project 
scheduling, and the Plan and Manage Schedule task in the Process domain of the Examination Content Outline (ECO) is 
another. Remember that while much of the Process Groups model can be applied to any project life cycle and development 
approach, agile has its own methods and practices. You will also want to understand agile scheduling practices, and how 
they are similar and how they are the different from plan-driven practices. 


The Examination Content Outline and Process Groups Model 


Think About It. Take time now with the ECO and the following diagram to think through the Process Groups 
model’s Schedule Management process as it relates to the Plan and Manage Schedule task from the ECO’s 
domain I (Process). 


+ In the Process Groups model, these are all planning functions: 
O Define activities 
Sequence activities 
| Estimate activity durations 
* Then you are ready to develop the schedule—also a planning function. 


+ Throughout the project you are using earned value measurement (EVM) to control the schedule (including 
procurement schedules) and manage changes to it. EVM is covered in more detail in “Budget and Resources,” 
as it is used for tracking progress on scope, schedule, and cost together. 
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ECO Process Groups Model PMBOK® Guide 


Domain II Schedule Management Domain 2.4 
Planning 
Task 6 Plan Schedule Management —: Domain 2.7 
Plan and Manage Schedule 
2 Define Activities Measurement 
Blanning) Domain 2.8 
Sı Activitie 5 
equence Activities ERS 
Estimate Activity Durations 
Develop Schedule —' 
Monitoring 
Control Schedule — & Controlling 


Can you see how other ECO tasks support Plan and Manage Schedule? For example, supporting ECO processes are 
Manage Conflict and Negotiate Project Agreements (People domain I, tasks 1 and 8). Also think about the supporting 
roles of Promote Team Performance through the Application of Emotional Intelligence, and Ensure Team Members/ 
Stakeholders Are Adequately Trained (People domain I, tasks 14 and 5). Think systematically as you review the ECO. 
Other ECO tasks also often play a role in planning and managing the project schedule. 


Key 
Continuous change control 
7 is consistent with all 
approaches 


Change prompts a process 

C to be reiterated through 
progressive elaboration 
or agile methods 


.—Clignges that cause a 
return to Initiating are rare 


Remember, 
it's iterative 


Planning 


M&C 


FIGURE 8.1 Schedule management process 


Desired Outcomes of Schedule Management 

For the exam, unless the question indicates otherwise, assume that schedule management has been properly planned 
according to the concepts presented in this chapter related to planning and managing the schedule. Having a plan means 
that when a problem arises the first option is to look to the plan for how to handle it. The following should be expected of 
a properly planned and managed project: 
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+ All or most deliverables are completed and delivered in the planned timeframes, within budget and with the agreed 
quality attributes. 


* The number of changes to the project and product requirements are within the project manager and team 5 expectations. 


v More changes are expected on agile projects than on plan-driven projects. Negotiating scope to keep the 
project on schedule on agile projects is also expected as scope is understood to be the more flexible constraint. 


v A significant number of changes to requirements on plan-driven projects should be evaluated for possible 
issues with stakeholders or the clarity of the scope and requirements definitions. 


* Stakeholder behaviors and relationships indicate project outputs are largely accepted and stakeholders seem satisfied 
at a given point. 

+ The cadence of development, testing, and implementation is appropriate to the specific project and to the development 
approach and life cycle selected. 


+ Measurements indicate the project is performing as planned. Reviewing past forecasts against present project 
performance indicates the project is largely or wholly on schedule. 


+ Project benefits can be realized in the timeframe they were planned for. 


Plan Schedule Man: ent 


The Plan Schedule Management process involves documenting how you will plan, 
manage, and control the project to the schedule baseline, and how you will manage 
schedule variances. You also need to determine in advance and ensure a common 
understanding about: 


+ What the measures of performance will be 
+ How and when to capture data to evaluate performance 
+ How you will use the data to keep the project on track 


+ What you will do when variances occur 


Plan Schedule Management answers questions such as: 


+ Who will be involved, and what approach will be taken to plan the schedule for the project. 
+ What processes and procedures will be used to create the schedule? 


Did you remember that hybrid and agile approaches take a more short-term view of scope and schedule 
than traditional approaches? Teams form a general plan and then schedule and perform project work in 
iterations. They then re-evaluate to determine the next best steps based on actual progress. Agile teams also Agile 
continually refine the schedule as new details emerge. This approach is best when trying something new. non 
When the work is new and scope is emerging rather than stable, discovery is a better guide for progress than detailed analysis. 


When work and environments are familiar and predictable, it is possible to accurately schedule work in advance. A 
hybrid approach uses traditional scheduling methods in some areas of the project while using agile methods in others. 


Example A traditional approach is typically used to build an office building. A realistic hybrid option is to start and 
finish the building's most durable aspects using a traditional approach, and then customizing the inside spaces iteratively 
as office space is leased. 


To plan the projects'’schedule, the project manager will also need to: 
+ Review the project charter 
+ Use expert judgment 
* Use data analysis techniques, such as alternatives analysis 
+ Hold meetings that include the: 
y project sponsor 


y team members 


y other stakeholders 
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The project life cycle and development approach agreed on in Develop Project Management Plan (an Integration 
process) will influence the level and type of schedule management planning the project manager does. They may also 
consider using or creating enterprise environmental factors, such as: 

+ A work authorization system for the project 

+ A preferred project management scheduling software, which the organization may already have 


+ The impact of the company culture and overall structure on the project schedule 


Schedule Management Plan What is the key output of this process? A formal or informal schedule management plan 
(part of the project management plan). It helps make estimating and schedule development faster by specifying 
the following: 


+ Scheduling methodology and software + How schedule variances will be managed 

+ Rules for how estimates will be stated (Examples: + Performance measures that will help identify 
hours, days, story points) variances early 

+ Whether to state both effort and duration + Acceptable variance threshold (s) 

+ How a schedule baseline to measure against will + A process for determining whether a variance must 
be stated be acted on 

+ Estimates for where changes may occur * Types, formats, and frequency of reports needed 

+ Change control procedures + Length of iterations and releases for agile 


Define Activities 


The Define Activities process involves doing the following for the work packages cre- 
ated in the WBS (created as part of Plan and Manage Scope): 
+ Decomposing them into the activities that are required to produce the 
work packages 
+ Making sure decomposition is at a level small enough to: 


x/ Estimate 
y Schedule 


y Monitor and control 


+ Prepare to sequence these activities in the next process 


The Context for Defining Activities 

Project managers often combine the Define Activities effort with creating a WBS and WBS dictionary. The project manager 
and team decompose work packages into the activities required to produce them, rather than stopping at the work package 
level. So, what is needed in order to define activities? 


+ The schedule management plan gives the project manager important information about the agreed sched- 
uling methodology 
+ The traditional scope baseline (scope statement, WBS, and WBS dictionary), or the projects product backlog for 
agile projects 
* Story cards for agile projects 
This is the work the project manager will now break down into project activities. Collaborating with the team helps 
define activities completely and accurately and later will make the estimates more accurate. The project manager may refer 
to organizational process assets, including: 
+ Existing templates, 
e Historical information such as: 
v Activity lists 


m/ Issue lists from other similar projects 


+ Standards, such as prescribed scheduling methodologies 
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While reading exam questions remember to identify: “Where am I in the project management process?” 
Decomposition is used in schedule, scope, and cost management. When you see the term “decomposition” on 


work packages) the question is referring to the Create WBS process (in scope management) and a predictive 
approach. If work packages are being broken down into activities to produce them, the question is referring to Define 
Activities; (for schedule management). 


I With an agile approach, the team helps to define the activities and the product owner sequences the work by 
prioritizing stories in the backlog. The team helps identify dependencies, develop estimates, and provide input 
on what is achievable. Development of the schedule is a joint effort. 


Sequencing Activities 


Once work package activities are defined, the next process involves sequencing them 
in the order in which the work should be performed. The result is a project schedule 
network diagram. A simple network diagram is illustrated in figure 8.2. There is prac- 
tice work designed to help you learn how to draw and interpret network diagrams 


later in this chapter. 


FIGURE 8.2 Network diagram 


For the exam, know this about a network diagram: 
+ In its simplest form, it just shows dependencies between activities. 


+ If activity duration estimates and leads and lags are added to the diagram, it can also show the critical path, which is 
the shortest path to finishing the project. 


+ Ifplotted out against time (is made calendar-based), the network diagram is a time-scaled schedule network diagram. 


Inputs that may influence dependencies in the sequencing of activities include the: 
+ Assumption log 

e Activity list 

e Activity attributes 

e Milestone list 


Precedence Diagramming Method (PDM) 
This method uses nodes (or boxes) to represent activities, and arrows to show dependencies. In figure 8.3, for example, 
activity B is dependent on the completion of activity A. 


FIGURE 8.3 Precedence diagramming method 
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Logical Relationships 
There can be four types of logical relationships between activities, as shown in figure 8.4. 


Finish-to-start (FS) An activity must finish before the successor can start. This is the most commonly used 
relationship. Example: You must finish digging a hole before you can start the next activity of planting a tree. 
Start-to-start (SS) An activity must start before the successor can start. Example: You must start designing and wait 
for two weeks’ lag in order to have enough of the design completed to start coding. 

Finish-to-finish (FF) An activity must finish before the successor can finish. Example: You must finish testing 
before you can finish documentation. 

Start-to-finish (SF) An activity must start before the successor can finish. This dependency is rarely used. An 
example of this type is, “The first shift security guard cannot leave until the second shift security guard arrives.” 


Start-to-start: 


Finish-to-finish: 


FIGURE 8.4 Finish-to-start, start-to-start, and finish-to-finish dependencies 


Types of Dependencies 
The sequence of activities is also determined based on these dependencies: 
* Mandatory dependency (hard logic) A mandatory dependency is inherent in the nature of the work or is required 
by a contract. Example: You must design before you can construct. 
¢ Discretionary dependency (preferred, preferential, or soft logic) This means there are other ways it could be done, 
but this is the approach the organization has chosen to perform the work. Discretionary dependencies are the most 
flexible type, and they are important when analyzing how to compress the schedule to decrease the project duration 
(i.e., to fast track it). 
* External dependency This type of dependency is based on the factors relating to a party outside the project (for 
example, government or suppliers). 
+ Internal dependency This type of dependency is based on needs internal to the project and may be something the 
project team can control. 
More than one dependency can be identified for the same work. Combinations include: 
+ Mandatory external + Discretionary external 


+ Mandatory internal + Discretionary internal 


Dependencies in Hybrid Environments 

Digital products have different characteristics than traditional, physical products. Consider how a contractor 

builds a house. They wouldn’t complete the interior of the house before they built the roof, would they? Of 

course not. The roof needs the walls, the walls need a foundation, and the foundation needs land and permits Agie 
in place. The dependencies are static, well understood, and slow to change. Techniques like network diagrams, Focus 
critical path analysis, and detailed Gantt charts are valuable and necessary. 


In the digital product space, however, there are many more options and possibilities. Good IT architecture allows 
services to be swapped out easily and promotes isolating changes. This means there are far fewer dependencies on digital 
projects. This coupled with more requirements renders much of the traditional dependency analysis and dependency 
management redundant, unreliable, and wasteful. Therefore, many of these techniques are not used in software-heavy 
digital projects. Instead, project managers work with product owners to define what the priorities are, and they work with 
the teams on how best to build them. Typically, features can be implemented and evaluated independently of each other. 
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For example, using a hybrid approach to build an energy trading system for an electrical operator, the product owner 
may use a traditional approach to create an initial sequence of features to be developed. Then they may reorder the 
remaining features once the initial product is in place. The product owner may reorder these features again after the 
regulatory body responses get integrated, and again later as additional features come on board. This would all require 
extensive schedule rework with traditional network diagrams and Gantt charts. By comparison, reordering the backlog at 
this stage of a hybrid project is much less work. 


Project Schedule Network Diagram 

A schedule network diagram is an artifact of planning and managing the project schedule. It is an illustration depicting the 
flow of project activities in the logical order in which they will be performed (see figure 8.11). Here are some guidelines to 
understand about schedule network diagrams: 


The project manager needs the activities list and to know the dependencies between activities. Later, after they have 
all the duration estimates for each activity, they can add that data to the network diagram. 

All activities after the Start should be connected to at least one predecessor activity (except the first one in each 
workstream after Start). 

All activities on the network diagram before the Finish should be connected to at least one successor activity. 

The network diagram helps the project manager plan which activities can be completed in parallel and to see where 
leads or lags are required. 


The more complex the project, the more likely it is that activities will overlap. 


Path convergence An activity having two or more activities directly preceding it on different paths is referred to as 
path convergence. 


Path divergence An activity having two or more successor activities directly following it on different paths is referred 
to as path divergence. 


Both path convergence and divergence are indicators of risk within the impacted activities. 


Example Using the simple example in figure 8.2, here is how to build a network diagram. 


1. Put <Start> and <End> in shapes that distinguish them from the nodes (named activities). 


2. From <Start>, create the first rectangle and label it Activity A. 


Draw a line from Activity A and add another node, labeling this second node Activity B. The line indicates a 
dependency connection between the two 


4. Draw a line from Activity B and add another node, labeling this third node Activity C. 
5. Add an <End> and draw a line from Activity C to <End>. 


6. Repeat the process to add the second path (add Activities D and E; add lines between them and then a line to 
<End>. The network diagram is ready for the activity duration estimate data. 


Complex project schedule network diagrams that include leads and lags as well as other dependencies are best done 
with an automated scheduling system that is part of the PMIS. You will be expected to answer questions on the exam 
related to interpreting information these diagrams provide. You need to have worked with network diagrams to accurately 


answer such questions. 


In summary, network diagrams can be used to: 


+ Help justify the project manager s time estimate for the project. 


+ Aid in effectively planning, organizing, and controlling the project. 


+ Show interdependencies of all activities, and thereby identify riskier activities. 


+ Show workflow so the team will know what activities need to happen in a specific sequence. 


+ Identify opportunities to compress the schedule in planning and throughout the life of the project (explained later in 
this chapter). 


+ Show project progress and help with forecasting. This is used for controlling the schedule and reporting, and is related 
to earned value measurement (EVM). EVM is related to scope, schedule, and cost, and is covered in the “Budget and 


Resources” chapter. 
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Estimating Activity Durations 


When the activities have been defined and sequenced, the next step is to estimate how 
long each activity will take. This is the Estimate Activity Durations process. When 
possible, estimators should be those who will be doing the work, or on large projects, 
members of the project management team most familiar with the specific work to be 
done. 

Both the Estimate Activity Durations and Estimate Costs (in the “Budget and 
Resources” chapter) processes involve estimating. Historically, the exam has focused 
on the methods required to produce good estimates more than on calculations. 

Use this checklist to evaluate your understanding of activity and schedule 
estimating. Identify gaps that may impact how you answer exam questions. Keep 
track of items you currently do not do in your project work and pay extra attention to 
studying these topics. Remember, bad project management practices (like padding estimates, for example) may be listed 
as choices on the exam. 


kA „Thi 


Management plans provide the approach to estimating. 
E DThe project manager and team may use one or many techniques to estimate project work. 


Estimating should be based on small amounts of work, from a WBS or from story cards in agile. This 
improves accuracy. 


Duration, cost, and resource estimates are interrelated. Duration and resource estimates often impact cost estimates. 


Identified risks must be considered when estimating the duration, cost, and resource requirements of project 
work. Risk management actions are specific line items in a project contingency reserve (part of the budget). For 
agile risk management actions are represented as stories in the backlog. 


Estimating duration, cost, and resource requirements may uncover additional risks. 
Estimating should be done by those doing the work or those most familiar with it to improve accuracy. 


Historical information from past projects (part of organizational process assets) is often key to getting started and 
improving estimates. 


Estimates are more accurate on smaller-size work components. 


A project manager doesn’t just accept management-given constraints. They evaluate project requirements, develop 
estimates with the team and reconcile differences, producing a realistic plan. 


The project manager may periodically recalculate the estimate to complete (ETC) for the project to ensure 
adequate time, funds, and resources for the project (getting needed approved changes). ETC and other project 
control metrics are discussed in the “Budget and Resources” chapter. 


Plans based on estimates should be revised, with approved changes, during completion of the work, as necessary. 
There is a process in the project management plan to create the most accurate estimate possible. 

Padding estimates is not an acceptable project management practice. 

The project manager must meet any agreed-upon estimates. 


Estimates (from team members or sellers) must be reviewed to ensure they are reasonable and do not contain 
padding or unidentified risks. 


Estimates must be kept realistic throughout the project by re-estimating periodically as needed. 
Estimates can be positively impacted by reducing or eliminating risks. 


The project manager has a professional accountability to (with the help of the team) provide estimates that are as 
accurate as feasible, and to maintain the integrity of those estimates throughout the project. 
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Inputs to Good Activity Estimates 


To arrive at realistic time estimates, these individuals need to have access to the following: 


Activity List and Activity Attributes The relevant inputs may include the time for required leads or lags between 
activities, which must be factored in to duration estimates. 


Assumption Log Assumptions or constraints that contribute to risk within the activities to be estimated should be 
found here. 


Lessons Learned Register Information relevant to the duration of activities include lessons learned from earlier in the 
current project or from past, similar projects within the organization. 


Resource Breakdown Structure Created in the Estimate Activity Resources process (of Resource Management), the 
resource breakdown structure shows categories of resources required for the project. 


Resource Requirements These requirements indicate the skills needed from resources to perform specific project work. 


Project Team Assignments Team assignments should include the number and experience level of individuals who have 
been committed to the project. 


Resource Calendars These calendars provide information on when key resources with specialized skills needed for 
activities will be available. If the resources are not available within the timeframe of the project, the project manager needs 


to estimate time for those to allow less experienced resources to do the work. 
Risk Register The risk register may include identified threats and/or opportunities that should be reflected in the estimates. 


The Knowledge to Avoid Padding A pad is extra time or cost added to an estimate because the estimator does not have 
enough information or feels insecure in their estimating. It is not a viable way to plan a project. What is wrong with 
padding? Think about how estimating works on your projects for a moment. Can you see how, if individual team members 
pad their estimates, the project estimates become increasingly unreliable? In turn, padding undermines the ability to create 


a realistic schedule and budget. 


In cases where the information required to clarify the unknowns is unavailable, the potential need for additional time 
or funds should be addressed with reserves within the risk management process. Through risk management, uncertainties 
are turned into identifiable opportunities and threats. Uncertainties then do not remain hidden. 


Remember it is a PMI-ism that proper project management has been done unless an exam question indicates 
otherwise. There is no need for padding when the following is in place in a properly managed project: 


* The estimators have a WBS and may even have helped create it. 
* They also have a description of each work package (the WBS dictionary) and may have helped create that as well. 
* They may even have helped create the activity list from the work packages. 


* Three-point estimates can be used, which by averaging the worst-case scenario, the most likely scenario, and the best- 
case scenario, builds uncertainty into the estimate. 


+ The estimators know there will be time and cost reserves on the project determined through the risk management 
process to address identified risks. 
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How Estimating Is Done 
The part of the team doing the estimating may use one or many techniques as identified earlier in the schedule 
management plan. 

First, lets' look at the project manager s role in estimating. The project manager s role here is to: 

+ Provide the team with enough information to properly estimate each activity. 

+ Let those doing the estimating know how refined their estimates must be. 

+ Complete a sanity check of the estimates. 

+ Prevent padding. 

+ Formulate a reserve (more on this in the “Risks and Issues” chapter). 


+ Make sure assumptions made during estimating are recorded for later review. 


Now let’s look at estimating techniques that may be used on a project. We have organized the following two sections 
into predictive and adaptive estimating techniques. These methods are generally used with these approaches and are likely 
to appear on the exam in these contexts. However, any variety of these techniques may be used, especially with a 
hybrid approach. 


Methods for Predictive Estimating 
Traditional projects use the following methods for estimating. Analogous estimating is an example of an estimating practice 
applicable to both predictive and adaptive approaches. 


Analogous Estimating (top-down) Analogous estimating uses expert judgment and historical information to estimate. 
It can be applicable to time, cost, and resources. It is usually not considered definitive. For example, management or the 
sponsor might use analogous estimating for high-level estimation while establishing a business case and for project 
selection. As the project is chartered the project manager may use analogous estimating at the project level, using historical 
data from past, similar projects. For example, “the last five projects similar to this one each took eight months, so this one 
should as well.” Analogous estimates are refined later during planning. 


Analogous estimating can also be used at the activity level if the activity has been done on previous projects and if 
there is substantial historical data to support accuracy. For example, “This company has created many thousands of 
programming modules and they have taken an average of X hours so we will use that as a starting point.” 

On the other hand, analogous estimates are used when there are little supporting data. For example, “The last two 
times this activity was done each took three days. Since we have no other data to go on, we will estimate three days and 
review estimates as we learn more details.” 


TRICKS For the exam, know analogous estimating can be done at various times. It is usually not thought to be definitive 


but the level of accuracy can also depend on how much analogous data are available and how closely the project 
y p g y proj 
or activity matches the historical record. 


Bottom-up Estimating 


This method involves creating detailed estimates for each activity or work package, using an accurate WBS. The individual 
estimates are then rolled up into control accounts and finally into an overall project estimate. You will see how these 
estimates roll up into a budget in the “Budget and Resources” chapter. 


Parametric Estimating 


Parametric estimating involves a mathematical equation using data from historical records or other sources, such as 
industry requirements or standard metrics. The technique analyzes relationships between historical data and other 
variables to estimate duration or cost. It can be applied to some or all the activities within a project. For example, when 
estimating activity duration, the estimator may use measures such as time per line of code, time per linear meter, or time 
per installation. When used in cost estimating, the measures include cost as one of the variables. So the measures would be 
cost per line of code, cost per linear meter, etc. 
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An estimator might create parametric estimates using the following: 


Regression Analysis (Scatter Diagram) This diagram tracks two variables to see if they are related; the diagram is then 
used to create a mathematical formula for future parametric estimating. Figure 8.5 shows an example of a scatter diagram. 


Learning Curve (by example): The 100th room painted will take less time than the first room because of 
improved efficiency. 


N 
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a 


T T 1 
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FIGURE 8.5 Regression analysis (scatter diagram) 


Single-point Estimating (One-point Estimating) _ 

This type is based on a single estimate; however, it can be problematic. For example, the person doing the estimate may say 
that an activity will take five weeks. This may be based on expert judgment or historical information, or it could be just 
a guess. 


One-point estimating can have the following negative effects on the project: 

+ Being limited to making a one-point estimate may encourage people to pad their estimates since it doesn’t include 
best- and worst-case scenarios. 

e When a persons éne-point estimates turn out flawed—for example an activity takes 15 days instead of an estimated 
20, it can make the project estimates and estimators seem unreliable. 

+ One-point estimating can result in a schedule that no one believes in, thus decreasing buy-in to the project 
management process. 


We can come together to use single numbers for project activity estimates, for example, using a more realistic 
estimating method like three-point estimating, covered next. For each activity, it is easier to use a single number (of days, 
for example) to draw a network diagram and find the project s critical path. On the exam, one-point estimates allow for 
quick calculation (if a question supports that) and demonstrates that you understand concepts such as the critical path. 


Three-Point Estimating (a version of multi-point estimating) _ 
Estimates are best given in a range since there is a very small probability of completing a project on exactly any one date. 


Three-point estimates are the best known of multi-point estimating techniques. 

Three-point estimates better account for uncertainty: What could go right (opportunities) and what could go wrong 
(threats), to help estimators determine an expected range. This way the project manager can better understand the potential 
variation of the activity estimates. 

There are two ways of calculating three-point estimates for the exam, as follows. Memorize these formulas and 
remember they can be used for both time and cost estimates: 


Triangular Distribution (Simple Average) A triangular distribution of the three-point estimates can be calculated using 
the formula (P + O + M)/3. The use of simple averaging gives equal weight to each of the three-point estimates when 
calculating the expected activity duration or cost. Using this formula, the risks (or the uncertainties, which are the P and 
O estimates) are considered equally along with the most likely (M) estimate. 
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Beta Distribution (Weighted Average) The beta distribution (a weighted average) gives more consideration to the most 
likely (M) estimate. This method uses the formula (P + 4M + O)/6, a weighted average. When a good risk management 
process is followed, the most likely estimates are more accurate because risk response plans have been developed to deal 

with identified opportunities and threats that have been factored into the pessimistic and optimistic estimates. 


ee Think About It. For the exam, know these formulas and how they are applied to estimating. 


Ei Expected activity duration Expected activity duration 
(triangular distribution) (beta distribution) 
P+M+0 P+4M+0 
3 6 


Legend: P = Pessimistic, M = Most likely, 0 = Optimistic 


FIGURE 8.6 Three-point estimating formulas 


If you are asked to calculate the activity duration or cost, read the situation carefully to determine which 
formula to use. Terms like “simple” or “straight” refer to triangular distribution. “Weighted” refers to beta 
TRADE. distribution. Knowing this will help you choose the correct formula. 


You may be asked to perform a calculation or just analyze information to determine which formula is best for the 
scenario. Use triangular distribution if the scenario indicates that the project manager doesn’t have a lot of experience or 
historical information; it provides a straight average. Use beta distribution when there are historical data or samples to 
work with. Most of exam questions relating to this are relatively simple and may require assessment but not calculations. 
But the calculations are not difficult and the following exercises can help you prepare for them. First, review the three-point 
estimating formulas in figure 8.6. 


8.1 Exercise (Triangular Distribution) 
Calculate the expected activity duration using triangular distribution. You may write the answer here or use your 
Exercise Notebook. All estimates are in hours. 


Activity P M 0 Expected Duration 


A 47 27 14 
B 89 60 41 
C 48 44 39 
D 42 37 29 


Answer (Triangular Distribution) 


Activity Expected Duration 


A 29.33 
B 63.33 
C 43.66 
D 36 


Schedule 
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8.2 Exercise (Beta Distribution) 
Calculate the expected activity duration using beta distribution. You may write the answer here or use your Exercise 
Notebook. All estimates are in hours. 


Activity P M 0 Expected Duration 


A 


B 
Cc 
D 


47 27 14 
89 60 41 
48 44 39 
42 37 29 


Answer (Beta Distribution) 


Activity Expected Duration 


A 


B 
C 
D 


28.17 
61.67 
43.83 
36.50 


Compare the answers using triangular distribution to the answers for the beta distribution. It may seem that the 
results are not significantly different, but think about it in terms of a cumulative effect with many activities. 


Activity Standard Deviation This concept describes a possible range for an estimate. 


Example An activity estimate of 30 hours with a standard deviation of +/- 2 is expected to take between 28 hours 


and 32 hours. 


oe Think About It. You won’t be asked to calculate “beta activity standard deviation,” or (P - O)/6 but interpreting 
@ it in a situational question is important. Think through the following so you understand it. 


To establish a range for an individual activity estimate using weighted (beta) averaging, you need to know the beta 
expected activity duration (EAD) and the beta activity standard deviation (SD). The SD is likely to be given. You calculate 
the range using beta EAD +/- SD. 

The start of the range is beta EAD - SD, and the end of the range is beta EAD + SD. Review the following table to see 
how the information is presented. Keep in mind that the exam scenario may include information for you to do the same 


evaluation with triangular distribution. 


Activity 
A 


Beta Activity 

P M 0 Expected Duration Standard Deviation Range of the Estimate 

47 27 14 28.167 5.500 22.667 to 33.667, or 
28.167 +/- 5.500 

89 60 41 61.667 8.000 53.667 to 69.667, or 
61.667 +/- 8.000 

48 44 39 43.833 1.500 42.333 to 45.333, or 
43.833 +/- 1.500 

42 37 29 36.500 2.167 34.333 to 38.667, or 


36.500 +/- 2.167 
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Additional points to know: 


. 


. 


Understand that estimates of time (or cost) should be in a range. 

Although there is a standard deviation formula for triangular distribution, it’s complicated and is unlikely to be on the 
exam so we are not showing it here. What you need to remember for the exam is that the greater the standard deviation, 
the greater the risk. 

The formulas we’ve been discussing relate to activities. The exam concentrates on three-point estimates to find ranges 
for activity duration and cost estimates. Be prepared to do simple calculations using these formulas 

You may also see beta total project duration used in questions that require you to evaluate the situation rather than do 
a calculation (Example: The project duration is 35 months plus or minus 3 months). As with an activity, the greater 
the range for the project, the greater the risk. 

You can use these concepts to better monitor and control projects. The expected durations help you know the potential 
variances on your project and determine appropriate courses of action. 

You can use estimated ranges and standard deviation to assess risk. Looking back at the table presenting beta standard 
deviation, which activity has the most risk? The answer is Activity B. It has the widest range and the highest standard 
deviation, and is therefore likely to have the greatest risk. 


Methods for Adaptive Estimating 


It is worth repeating that while we have organized these sections into predictive and adaptive estimating 
techniques, any variety of these techniques may be used with approaches from predictive to hybrid to 
adaptive. For example, although it is common to think about “affinity estimating” in an agile context, 
categorizing activities on predictive projects into those taking more or less than 40 hours to complete is also 


a form of affinity estimating. 


Adaptive estimating is done in stages, using progressive elaboration. Story collection estimating typically begins with 


“t-shirt sizing” for the initial plan, which is refined during release and iteration planning, and throughout the project. 


Affinity Estimating 


This 


is a technique where groups of similar items are grouped into collections—i.e., “affinities.” For example, placing user 


stories into size categories makes it easier to see whether stories with similar estimates are, in fact, comparable in size. 


T-shirt Sizing 


A form of affinity estimating, or grouping like items together, t-shirt sizing is an approach to estimating product features 


and user stories early in the project. The team is not yet trying to generate thorough estimates. They are aiming for high- 


level (course-grained) estimates, sufficient to map out the overall project effort. 


Here is an example from a project for an online movie service. The team has identified six features: 


ES S M L XL XXL 
Sort movies Rate movies Browse Rent movies Sell movies 
by year movies 
Review 
movies 


FIGURE 8.7 Features by t-shirt size 


The results of the sizing effort are shown in figure 8.7. As you can see, it’s been decided that: 

+ “Sort movies by year” will require the least effort to build; this is Extra Small. 

* Two features that we think will take Medium effort are “Browse movies”; “Review movies.” 
+ An online shopping cart for “Sell Movies” will require the most effort; this is Extra Large. 


+ None of these features will require an Extra-Extra-Large effort. 
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Once the team has identified ES 5 M f YI YYI 
the features, they will decompose 
them into user stories. In figure 8.8, Sort malas Rate Browse Rent Sell 
the user story cards are stacked by year movies movies movies movies 
under each column. These user 2 user stories 5 user stories 8 user stories 7 user stories 14 user stories 
story cards represent the work = == 
estimated by the team to be done to s | | 
j e f m 
build the product. = ae = h 
You can see at a glance what J | 
will take the most effort to build : [ ] ] 
. i i j 
(“Sell movies” with 14 user stories) 7 L 
and what will take the least (“Sort Review = 
movies by year” with 2 user stories). movies 5 
É | 
It also appears that “Rent Susanne "L Z] 
movies,” which was sized Large, j = 
might actually be smaller than =] 
“Browse movies” and “Review j 


movies,” which were sized Medium. — 
However, the team has not yet = =a 

determined the relative size of the 

stories. Some of the stories may be FIGURE 8.8 Features and user stories 

very small, and others may be very 

large. The team has to estimate all 

the user stories in t-shirt sizes, like ES S 


they did for the features. 
= 


XXL 


After that, they can also use 
affinity estimating to ensure the 


stories in each category are 
comparable in size. The stories 
based on t-shirt sizes might look 
something like figure 8.9. 


Now that all the stories have 
been sized, the team can use the L 4 EP 
relative sizes of the stories in each = 
feature to refine their t-shirt 
estimates for each one. For 
example, let’s say they find out that, 
on average, the stories in “Rent movies” are larger than the stories in “Browse movies” or “Review movies.” Then “Rent 
movies” will require more effort than the two Medium features, as originally thought. 


FIGURE 8.9 User stories by t-shirt size 


Planning Poker* 


Planning Poker* is a common and collaborative game using relative sizing. The goal is not to create precise estimates. It 
aims to help the team quickly and efficiently reach consensus on reasonable estimates. The project can keep moving forward. 

Here’s how to play. An agile team gathers to estimate the stories that need to be built. Each player gets a set of cards 
with the numbers as shown in figure 8.10. Someone reads a story and each player evaluates it for the work effort they think 
it requires. The estimating process continues as follows. 


EIGHT Schedule 


Remember these stories are in a backlog that the product owner has prioritized. 
1. All at once (to avoid group think), each team member throws down a card (representing a number of story points). 
2. The group discusses differences. As they do this, they are discussing the work involved in each story. 


3. As needed, they play another estimating round or two before coming to consensus on the number of points 
assigned to the story. 


. They repeat this for all stories needing estimates. 
. For the project’s first iteration the team estimates how many stories they think they can complete. 
. Once the first iteration is complete, they compare estimated to actual story points completed. 


. The actual number of completed story points is used to select stories for the next iteration. 


onnn ss 


. After a few iterations they can average their story points for a working average, or velocity, of story points completed 
per iteration. They can adjust velocity as appropriate throughout the project. 


FIGURE 8.10 Planning Poker® estimating “game” cards 


It is important to note that story points have no value except as measured against other stories in the same project. Be 
careful if an exam question talks about comparing two team velocities (speed at which they can build stories). Comparing 
two teams’ velocities on two different projects is not relevant or useful. 


Methods for Data Analysis 


The process Estimate Activity Durations uses two forms of data analysis: alternatives analysis and reserve analysis. 


Alternatives Analysis 
When activity estimates are not acceptable within the constraints of the project, alternatives analysis is used to look more 
closely at the variables that impact the estimates. 

Example Comparing options such as outsourcing work versus completing it internally to meet a schedule constraint. 
Alternatives analysis involves evaluating the impact of each option on project constraints, including cost versus time saved 
and level of risk. This process will result in the determination of the best approach to complete project work within 
the constraints. 


Reserve Analysis 


This connects the topics of estimating and risk management. Estimating helps to identify more risks. Risk management 
reduces uncertainty in time and cost estimates. This is accomplished by evaluating and planning for significant opportunities 
and threats, including how they will be dealt with if they occur. Risk management saves the project time and money! 

As described in the “Risks and Issues” chapter, two types of reserves can be added to the project schedule (and 
budget): contingency reserves and management reserves. 


Contingency Reserves Contingency reserves are allocated in the schedule baseline for identified risks after the Plan Risk 
Responses process. Significant risks to critical path activities may be managed by allocating a specific amount of schedule 
reserve. Employing contingency plans using contingency reserves helps keep the project within the schedule baseline. 


Management Reserves These are additional funds and time to cover unforeseen risks (or “unknown unknowns”) that 
may impact the ability to meet the schedule. Management reserves are not part of the schedule baseline. They may not be 
applied at the project manager s discretion. They require approval through the change control system. 
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Methods for Decision Making 

We’ve said that involving team members in estimating is beneficial because those most familiar with the work have the best 
understanding of the time required to complete each effort. This and the team’s inclusion in decision making increases 
their buy-in to the resulting schedule. Here are some group decision-making methods that are useful in project estimating 
- and in many types of decision making. Each are a variation on using voting in decision making. 


Plurality, Majority, or Unanimity _ 


On plan-driven projects, the project manager may take a simple vote to reach one of these, depending on the circumstances. 


Take the example of a scheduling decision regarding a small activity that is far into the future of the project and not on the 
critical path. The project manager may reach this decision with a simple plurality agreement, while one regarding an activity 
on the critical path in the near future may require a majority or unanimous agreement. 


Roman Voting 
Here people phyiscally show their level of support for a decision with a simple “thumbs up, thumbs down” voting style. 
“Thumbs sideways” can also be used for those who are not sure of their vote or have misgivings. 


Fist of Five 


This voting technique is commonly used on change-driven projects (and also called “fist to five”). In this 


variation, a closed fist indicates a zero (no support) and an open fist indicates five (full support). Team A 

members who are not supportive (who showed two or fewer fingers in the vote) share why they are not in Agile 

support of the option. Voting is repeated until everyone in the group indicates their support by showing at Fs 

least three fingers. 

Artifacts of Schedule Estimating 

When the Estimate Activity Durations process is complete—including risk management processes—the 

project manager will have estimates, including reserves. Here are summaries of outputs from this process re- A 

lated to both predictive and adaptive projects. These may be already-existing artifacts that are being updated. Agile 
Focus 


Predictive Project Outputs Adaptive Project Outputs 

— Activity attributes — Prioritized backlog of user stories 
—Assumption log updates — Coarse-grained estimates of user stories 
— Lessons learned register updates = Release goal focused on customer value 


— Target release date or release number 


Basis of Estimates Another artifact of estimating activity durations, the basis of estimates, explains how estimates were 
derived, including assumptions, constraints, what risks were taken into consideration. Basis of estimates also includes the 
confidence level for the estimates, expressed as a range, such as plus or minus 20% within which the actual project results 
are expected to fall. 
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Develop Schedule 


Once the network diagram and activity duration estimates are completed—or for ag- 
ile a release plan, feature and story prioritization in a backlog, and estimates—it is 
time to create a schedule model. This can be done using a variety of software tools 
within a PMIS. 

For traditional projects, the schedule model is the first schedule rendition and 
may be updated throughout the project based on approved changes. During the 
original project planning it is iterated until ready for approval. It is created using 
project data gathered thus far, including: 


+ Activities * Dependencies 
* Start dates (for activities without dependencies) * Leads and lags 


* Duration estimates 


Think About It. Representations of the schedule include milestone charts and bar charts (as often shown 

$ through Gantt chart view in project management software). Once approved, the schedule becomes part of the 
9 projects’ baseline (which is part of the project management plan). It is calendar-based, comprehensive, and 
realistic. Inherent in it are contingency reserves to manage risk. Consider what creating a schedule model involves. 


Let’s start at the beginning. What do you need before you can develop a schedule for your project? To develop a 
schedule, you need to have: 


e Historical records of previous, similar projects + Activity duration estimates 


including lessons learned + Resource requirements estimates 


+ Schedule management plan and scope baseline * Resource calendars 
* Defined activities (activity list and attributes) + The required resources by category (resource 
e Milestone list breakdown structure) 
+ Assumption log + A company calendar identifying working and 
+ The order in which the work will be done nonworking days 

(network diagram) + Already existing project team assignments list 
+ Basis of estimates + Risk register 


8.3 Exercise 


As a project manager, you need to use the estimating data and other inputs to create a schedule that you will be able 
to stake your reputation on meeting. What do you need to do to create such a schedule? Write the answer in your 
Exercise Notebook. 
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Answer 


The Develop Schedule process really includes everything you need to do to develop a finalized schedule that is 
bought into, approved, realistic, and formal. This is what developing the schedule is all about. What do you need to 
do to get it to that level? 


e Work with stakeholders’ priorities. 

+ Look for alternative ways to complete the work. 

+ Look for impacts on other projects and on operations. 

+ Take into consideration the skill levels and availability of known resources assigned to the team. 
+ Apply leads and lags to the schedule. 

+ Compress the schedule by crashing, fast tracking, and reestimating. 


+ Adjust components of the project management plan as necessary (for example, change the WBS to reflect 
planned risk responses). 


+ Input the data into a scheduling tool and perform calculations to determine the optimum schedule. 


+ Simulate the project using Monte Carlo and other analysis techniques to determine the likelihood of 
completing the project as scheduled. 


+ Optimize resources if necessary. 


e Give the team a chance to approve the final schedule; they should review the calendar allocation of their 
estimates to see if they are still feasible. 


+ Conduct meetings and conversations to gain stakeholder buy-in and formal management approval. 


The Develop Schedule process is iterative and can occur many times over the life of the project (at least once per 
project life cycle phase on a large project). The Develop Schedule process is a source of problems on the exam for many 
project managers. The exam will test you as an expert in handling schedule development during project planning and 
whenever there are changes to the project. 


Schedule Network Analysis 
Schedule network analysis is used to analyze and iterate the schedule model until the project schedule is approved. This 
analysis may use one or more of the following techniques: 

e Critical path method + Resource optimization 

* Schedule compression + Agile release planning 


+ What-if analysis (e.g. Monte Carlo analysis) 


Critical Path Method 

The critical path method involves determining the earliest and latest times each activity can start, and the earliest and latest 
times each can be completed. In software this can be done by entering activity start dates and durations. Where activities 
have dependent activities following (or succeeding) them, the software can calculate succeeding start and finish dates 
using duration data. Understanding this method requires you to understand the following basic concepts. 


Using the Critical Path As the longest duration path through a network diagram, the critical path determines the shortest 
possible duration for the project. It is along this path that there is the least schedule flexibility. The easiest way to find the 
critical path is to identify all paths through the network diagram and add the activity durations along each path. The path 
with the longest duration is the critical path. Be sure you do the exercises that follow and practice doing this work for 
the exam. 
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Near-Critical Path This path is closest in duration to the critical path and should also be watched closely. The closer in 
length the critical and near-critical paths are, the more risk the project has. Close monitoring and controlling activities on 
both the critical and near-critical paths (yes, there can be more than one) is needed to ensure the project can finish on time. 


Using Float For the exam, you should understand float and be able to calculate it. Note that the terms “float” and “slack” 
mean the same thing. Slack is an older term and is rarely used anymore. It is unlikely that you will see it on the exam but 
know it just in case it is used. Here are the three types of float to know for the exam. 
¢ Total float The amount of time an activity can be delayed without delaying the project end date (or an intermediary 
milestone) while still adhering to imposed schedule constraints. 
° Free float This is the amount of time an activity can be delayed without delaying the early start date of its successor(s) 
while still adhering to imposed schedule constraints. 
e Project float Also known as positive total float, this is the amount of time a project can be delayed without delaying 
an externally imposed project completion date required by the customer or management, or the date previously 
committed to by the project manager. 


Other things to know about float are: 

+ Activities on the critical path have zero float. 

* Total and free float are related to activities. 

e Project float is specific to the entire project. 

e Negative float results when externally imposed completion dates are not feasible. These issues must be addressed in 
planning to ensure the approved schedule is achievable. 

e Ifcritical path activities are delayed, negative float analysis helps in looking for corrective actions to bring the schedule 
back within the schedule baseline. 


When you know the critical path(s) and near-critical path(s), you can use float as a way to achieve better allocation of 
resources. 

Example If you have a resource who has the needed skill set but is not very experienced, you can assign them to work 
on activities with float. Even if their activities take longer, the project is less likely to be delayed. 

Knowing float also helps team members juggle their work on multiple projects. The amount of float tells them how 
much time flexibility they may have for each activity they are assigned to. Collaborating with the project manager, they may 
flex the exact start time of some activities with float. 

Sometimes the exam questions are presented in such a way that you can simply see the amount of float, but other 
times you will need to calculate it. Float is calculated using either of the following equations: 

+ Float = Late finish (LF) - Early finish (EF) 

+ Float = Late start (LS) - Early start (ES) 


Either formula gets you the same answer. Here is a trick for remembering the formulas: 


Start Formula Finish Formula 
Float = LS - ES Float = LF - EF 


You determine whether to use the start or finish formula based on the information available. 


Example An exam question says: “You have a late start of 30, an early start of 18, and a late finish of 34.” How do you 
find the float? You know to subtract the two starts or the two finishes (using the previous trick). You have not been given 


two finishes, so you use the equation 30-18, which equals 12. 
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Practice with the Critical Path Method 


a Think About It. Now that we have discussed the basic concepts, let’s look at how the critical path method 
( ] d works. We’ll use the network diagram in figure 8.11 as an example. The letters in the boxes indicate the activities, 
@k and the numbers above the boxes indicate the duration of each activity. The critical path is identified by the 
bold arrows. 
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FIGURE 8.11 Critical path method 


+ To determine the earliest and latest each activity can start, and the earliest and latest each activity can end, perform a 
forward and backward pass through the network diagram. 

* Forward pass The “early” figures are found by calculating from <Start> to <End> of the project, following the 
dependencies in the network diagram. 

* Backward pass The “late” figures are found by calculating from <End> to <Start> of the project, following the 
dependencies in the network diagram. 


Let’s start with the forward pass. You need to calculate through the activities from <Start> to <End>, determining 
early starts and early finishes for all activities. This example uses zero as the early start for the first activity. Use figure 8.12 
to walk through this. 
Note: Some people, use 1 as the early start of the first activity; others use zero. Either method will get you the right 
answer. Pick one method and use it consistently. We use zero as the first activity’s early start because people consistently 
find it easier when learning this concept. 


= Fg 
ES = Early start 


Activity name 


EF = Early finish 
orion of LS = Late start 
is. LF = Late finish 


FIGURE 8.12 Forward pass through network diagram 


+ Itis important to look at path convergence (where paths meet). To calculate the early start and the early finish in a 
forward pass, you must account for all the paths that lead into that activity (notice activities F and G in figure 8.12). 


+ The same concept applies to the backward pass. To calculate the late finish and late start you need to consider all paths 
that flow backward into an activity (activities D and F in figure 8.12). 


To make it easier to follow, we will step you through a forward pass here (EF and ES in parenthesis are early finish and 
early start, respectively): 
1. In figure 8.12, paths converge at activities F and G. 
2. Therefore, you must do the forward pass on both paths leading up to activity F. So: 
/ Calculate the early finishes for activities D (EF = 4) and A (EF = 3). 21 0 
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+/ Select the latest early finish between activities D and A. Use it as the early start for activity F (since F cannot 
start until both D and A are complete). 


V Therefore, the early start of activity F is 4. 
ze Use the same process for calculating the early finish of activities E (EF =13) and F (EF = 12), before determining 
the early start of activity G (ES =13). 
Once you have completed the forward pass, you can begin the backward pass, computing the late finish and late start 
for each activity. The backward pass uses the duration of the critical path (in this case, 26) as the late finish of the last 


activity (or activities) in the network diagram. 
See figure 8.13 for the late start and late finish data. 


Duration 
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FIGURE 8.13 Backward pass through network diagram 


. Be careful at points where paths converge as you move through the network diagram. 
. Paths converge at activity F and at activity G. 
. Work from <End> backwards. First compute the late start of activities B (LS = 22) and G (LS = 13). 
. Select the earlier late start for the late finish of activity F (since activity F must be finished before either activity B 

or G can start). 
5. The late finish of activity F is 13. 
6. This same process should be used on activities E (LS = 4) and F (LS =5) before calculating the late finish for 

activity D (LF = 4). 

Once you finish calculating the starts and finishes, you have the data required to calculate float. It’s time to use those 


k uw W oa 


formulas. 


TRICKS What was that trick again? “There is a start formula and a finish formula, and we always begin late.” The 


ay formulas are: 
RADE 


Start Formula Finish Formula 
(For Forward Pass) (For Backward Pass) 
Float = LS - ES Float = LF - EF 


The activities with zero float are on the critical path (see the bold arrows). See figure 8.14 for the float of each activity. 
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FIGURE 8.14 Float of activities on network diagram 2 I I 
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oe Think About It. Practice will help you understand these concepts better. As you do the following exercise, think 


about how knowing float helps you manage your projects. On the exam there are not many questions requiring 
you to do these calculations, and you may not be asked to draw a network diagram. But understanding this entire 
process will help you get more questions right. 


8.4 Exercise 


Test yourself. In your Exercise Notebook, draw a network diagram based on the following information, and then 


answer questions 1-7 below. 


You are the project manager for a new project and have figured out the following dependencies: 


Activity 1 can start immediately and has an estimated duration of 3 weeks. 


Activity 2 can start after activity 1 is completed and has an estimated duration of 3 weeks. 
Activity 3 can start after activity 1 is completed and has an estimated duration of 6 weeks. 
Activity 4can start after activity 2 is completed and has an estimated duration of 8 weeks. 


Activity 5 can start after activity 4 is completed and after activity 3 is completed. This activity takes 4 weeks. 


Questions: 


ils 


> v 


What is the duration of the critical path? 


. What is the float of activity 3? 
. What is the float of activity 2? 


What is the float of the path with the most float? 


. The resource working on activity 3 is replaced with another resource who is less experienced. The activity will 


now take 10 weeks. How will this affect the project schedule? 


. A new activity 6 is added to the project. It will take 11 weeks to complete and must be completed before 


activity 5 and after activity 3. Management is concerned that adding the activity will add 11 weeks to the 
project. Another stakeholder argues the time will be less than 11 weeks. Who is correct? Use the original 
information (without the change to activity 3 listed in the previous question) to answer this question. 


. Based on the information in the previous question, how much longer will the project take? 


Answer 


There are many ways to answer these questions. If you learned another way in other project management training 


and are comfortable with that method, use it. Here is a simple way to compute the answers. 


1, 


The length of the critical path is 18. There are two paths here: 


Paths Duration 
Start, 1, 2,4, 5, End 18 
3 8 
3 2—>4 4 
at g ~ PA 5 be End 
SI 3 as 


Total length is 18 weeks 


Start, 1, 2,4, 5, End is the longest duration path and is therefore the critical path at 18 weeks. 
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2. The float of activity 3 is 5 weeks, per the following diagram, which shows how to calculate float using the 
forward and backward pass. 
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You can use either float formula to compute float: 
e Late finish - Early finish = 14 - 9 = 5, or 
e Late start - Early start = 8-3 = 5. 
3. The float of activity 2 is zero; it is on the critical path. An activity on the critical path generally has no float. 
4. The float of the path with the longest float is 5 weeks. There are only two paths in this example: 
a. Start, 1, 2,4,5, End and Start, 1, 3,5, End. 
b. Only the non-critical path (Start, 1, 3, 5, End) will have float. 
c. You can calculate the float for this path by adding the float for each activity: 0 + 5 +0 = 5. 
d. Therefore, the total float of the path with the longest float is 5. 


5. The resource change on activity 3 will have no effect. 


a. The length of path activities 1, 3, and 5 is 13. 
b. Adding 4 more weeks to the length of activity 3 will make that path 17. 
c. Since that path is still shorter than the critical path, the critical path does not change. 


d. The length of the critical path is still 18 weeks because activity 3 is not on the critical path. 
6. The stakeholder who says the time added to the project will be less than 11 weeks is correct. 

a. The new activity will be added to a non-critical path that has a float of 5 weeks. 

b. Therefore, adding 11 weeks will make this path the new critical path. 


c. The effect of adding an activity that takes 11 weeks is a delay to the project of 6 weeks. 


7. The project will take 6 weeks longer. (Note: If you answered 24, you did not read the question correctly!) 
Follow the bold arrows in the following diagram. 


3 8 


Note: If you want more practice, there is an extra float and critical path exercise on the RMC Resources page 


(xmels.com/rme-resources). 
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TRICKS The following are good questions to practice concepts related to the critical path, float, and network diagrams: 


+ Can there be more than one critical path? Yes, you can have two, three, or many critical paths. 
+ Do you want there to be? No; having more than one critical path increases risk. 

e Can a critical path change? Yes. 

+ Can there be negative float? Yes; it means you are behind schedule. 


e How much float does the critical path have? In planning, the critical path generally has zero total float. 
During project executing, if an activity on the critical path is completed earlier or later than planned, the 
critical path may then have positive or negative float. Negative float on the critical path requires corrective 
action or changes to the project to bring it back in line with the schedule baseline. 


* Does the network diagram change when the end date changes? Not automatically, but the project manager 
should investigate schedule compression options such as fast tracking and crashing, to meet the new date. 
Then, with approved changes, the project manager should change the network diagram. See Schedule 
compression in the next section of this chapter. 


e Would you leave the project with negative float? No; you would compress the schedule. If schedule 
compression efforts do not result in zero or positive float, you need to request a change to adjust the baseline. 


TRICKS If you manually create a network diagram while taking the exam, label it with the question number, in case you 
(0) |g Want to go back to it later. You may be able to reuse the same network diagram to answer additional questions 


kiy later in the exam. 


It is easy to miss paths in a network diagram. When attempting to identify a critical path, carefully look at each path 
to ensure you calculate them all before determining which is critical. 


Methods for Schedule Compression 

One of the most common problems on projects is a difficult or unrealistic timeframe. This problem can arise during 
planning when management or the customer requires a completion date that cannot be met, or during executing when the 
project needs to be brought back in line with the schedule baseline due to delays or changes. It is the project manager $ 
responsibility to present options and to make sure the project is achievable. Schedule network analysis techniques such as 
schedule compression can help. 

Schedule compression describes using methods such as fast tracking and crashing to decrease project length. Schedule 
compression can be used during planning. Beyond the initial planning period, schedule compression may be used during 
Perform Integrated Change Control and Control Schedule to evaluate options and manage the impacts of change. In this 
case the objective would be to control the schedule without changing the schedule baseline. 


Fast Tracking 


This technique involves taking critical path activities that were originally planned to be completed sequentially and doing 
them in parallel for some or all of their duration, as shown in figure 8.15. The down sides: Fast tracking often results in 
rework, usually increases risk, and requires more attention to communication. 


= — To 


FIGURE 8.15 Fast tracking 


~ Think About It. Which activity in figure 8.16 would you fast track to shorten the project? 
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Start 


Total length is 33 months 


FIGURE 8.16 Which activity would you fast track? 


Assuming the dependencies are discretionary: 

+ Activity H could be fast tracked by making it occur at the same time as (in parallel with) Activity G. 
+ Activities C and H could be fast tracked by doing part of Activity C in parallel with Activity H. 

+ Any other pair of activities on the critical path could possibly be fast tracked. 


Think About It. Let’s look at an example scenario to help you further think about fast tracking and creating 
options. This example may or may not have made use of a network diagram. 


E Example A cable TV provider was using a hybrid approach to implement web analytics tools. The team was 
asked to fast track the product launch to coincide with a large marketing push in response to competition from 
streaming channels. 
+ The product owner met with management to review the release map and product backlog. 


+ They identified scope that could be deferred until after initial launch, allowing most functionality to be 
elivered on time and accommodate the new promotion. 


+ The customer could at first create some reports in spreadsheets rather than relying on the tool, and 


wn 


ome metrics could be eliminated from scope or deferred. 


* The core data and decision-making frameworks would be delivered on time. 


+ Management approved the reduced functionality and workarounds. 


+ The team proceeded and delivered most of the business value in time for the campaign. 


+ The team prepared instructions and training for early buyers to mitigate the effects of a reduced 
reporting functionality. 


+ A future release of the project completed the functionality and retired the spreadsheets. 


Here, scope was compromised temporarily to fast track the schedule. This added some risk and reduced initial 
functionality. Yet it was an effective way to meet a decreased schedule requirement. 


Crashin; 
The schedule compression method called “crashing” involves adding or adjusting resources while maintaining the original 
project scope. Crashing by definition results in increased costs. It trades time for money. It may also increase risk. 

Example In the network diagram in figure 8.16, a contracted resource could supplement the internal resources 
efforts on a critical path activity. Another option to crash the project might be to buy a software application. This assumes 
either option adds cost but helps the team save time. 

In the cable TV provider scenario, it may also be possible to crash by adding resources and get all the functionality 
completed in time for the campaign. For the exam, remember that you need to identify all possible options and, if given a 
choice between crashing or fast tracking, select the choice or combination of choices with the least negative impact on the 
project, and adds the least risk. 


Think About It. If you have negative project float (meaning the estimated completion date is after the desired 
date), would your first choice be to tell the customer the date cannot be met and to ask for more time? No; the 
first choice would be to analyze what could be done about the negative float by compressing the schedule. In 

~ crashing or fast tracking, it is best to carefully consider all potential choices and then select the option or options 
that have the least negative impact on the project and/or adds the least additional risk. 
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Many project managers have gaps in their knowledge in this area. Lets review another scenario. Figure 8.16 shows 
that a project duration is estimated to be 33 months. But what if you’re given a constraint of 30 months? Options are listed 
in the following table to illustrate how the project duration may be shortened by three months. 


Option 


Reestimate. 


Execute Activities H and C 
in parallel. 


Add resources to Activity 
G from the within the 
organization (adds cost). 


Cut Activity H. 


Hire consultants to assist 
on Activity G, H, or C 
(adds cost). 

Move more experienced 
people to critical path 
activities (activities G, H, 
or C). 

Cut time by cutting quality. 
(Do not get excited! Read 


on.) 


Get more work done with 
the same number of 
resources. 


Say no; the project must 
have 33 months. 


How to Achieve It 
(or what it is called) 


Reduce risks. 


Fast track (compress 
schedule). 


Crash (compress 
schedule). 


Reduce scope. 


Crash (compress 
schedule). 


Compress schedule. 


Lower quality 
standards. 


Work overtime. 


Say it can’t be done. 


Explanation 

(including assumptions made) 

Look at the estimates and see which contain hidden risks. 

By reducing risks, estimates can often be lowered. This 

way, the project finishes faster. 

Will work if the dependency between activities H and C 
is discretionary. Or may add risk. 


Would work if adding resources to activity G is practical 
and there are resources available. 


Not the first choice as it may affect the customer; still, 
reducing scope should be considered an option. 


Would work if adding external resources to these activities 
is practical and resources are available. 


Would work if some of the critical path activities are being 
done by less experienced people, and more experienced 
people are available. 


Quality is a project constraint; lowering quality standards 
is an option. If it is feasible, it would probably be faster to 


complete the project with lowered quality standards. 
Might add risk. 


Not an option during project planning. There are many 
other ways to compress a schedule that do not have the 
negative effects of overtime. Save it for a last resort. 

A viable option only after other alternatives are exhausted. 
Always endeavor to provide options. 


Think About It. Now consider the following questions in thinking about which of the options listed are best. 
There is no way to know since the scenario is limited. The goal here is, as always, to consider the impacts of 


each one: 
a, 


+ Is the best option to cut time by lowering quality standards? 


+ What are the impacts of cutting quality? 


+ Is there another option? 


+ Why not do what many project managers do—ask for more resources? But adding resources also adds cost. 


+ Why not work overtime? Overtime is not free. Most organizations are working at close to 100 percent 
capacity. The project team working overtime runs the risk of burnout. Also, the possibilities for responding to 


emergencies for other projects are narrowed, putting other projects at risk. For the exam, don’t consider 


overtime a viable option until all other options are exhausted. 


+ Generally, it’s best to look at risks and then reestimate. Once you know that the schedule (or budget) must 


be reduced, investigate activity estimates that contain the most unknowns. Reduce or eliminate these risks, 


thus decreasing the schedule. Eliminate more risks; everyone wins! If this offers only a partial solution, you 


could continue looking to shorten the schedule with other methods. 
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Schedule Compression Summary i 


Look at the schedule compression options again, and review the impacts of each option. Note that these methods can 
apply to a project using any life cycle and development approach. 


Option General Impacts on the Project 
Fast track + Always adds risk 
* May add management time for the project manager 
Crash + Always adds cost 
+ May add management time for the project manager 
* May add risk 
Reduce scope * May save cost, resources, and time 
+ May negatively impact customer satisfaction 
Cut quality * May save cost, resources, and time 
* May increase risk 
+ Requires good metrics on current and desired quality levels to be effective 


* May negatively impact customer satisfaction 


There is an additional schedule compression exercise on the RMC Resources page (rmcls.com/rme-resources). 


8.5 Exercise 


Consider the following question and write the answer. You may choose to do so in your Exercise Notebook. 
Management has said to get the project completed two weeks early. What is the best thing to do? 


A. Consult the project sponsor 
B. Crash 
C. Fast track 


D. Advise management of the impact of the change 


Answer 


Did you get fooled by this question? Did you think you had to choose between crashing and fast tracking? There is 
no information provided to help you determine which one is better. Therefore, the best choice presented is D, 
advise management of the impact of the change. This is the best choice because you will have to assess the impact 
of the change and inform management of that no matter what else you do. There is no data to back up the other 
possible answers. 


The exam will include many such questions requiring you to know that a project manager needs to analyze first, create 
options to deal with the change, and then let management, the sponsor, the customer, or other parties know the impacts of 
their request (see the four-step process for handling changes in the “Integration” chapter). A project manager does not just 
say yes! Instead, after analyzing the change for its impact on all areas of the project (cost, risk, resources, etc.), they could 
say something like, “Yes, I would be happy to make the change, but the project will be delayed two weeks. And I will need 
two more resources, or the project will cost $25,000 more.” 


‘or questions about changes to the network diagram, make sure you look for shifts to new critical paths cause 
Tey For questi b hang hi k diag akı you look for shift itical path d 
(0) j: by the changes to the network diagram or to activity durations. 
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Data Analysis and Simulation 

In creating a finalized, realistic schedule, it is helpful to ask, “What if a particular factor changed on the project? Would that 
produce a shorter schedule?” The assumptions for each activity can change and, therefore, the activity durations can also 
change. One of the ways to calculate the effect of these changes is through what-if scenario analysis. One example is Monte 
Carlo analysis. 


Monte Carlo Analysis __ 


This technique uses computer software to simulate the outcome of a project, based on the three-point estimates (optimistic, 
pessimistic, and most likely) for each activity and the network diagram. It is more accurate than other methods because it 
simulates the actual details of the project and calculates probability. 

The simulation can tell you: 

+ The probability of completing the project on any specific day 

* The probability of completing the project for any specific cost 

* The probability of any activity actually being on the critical path 


+ An indication of the overall project risk 


Monte Carlo analysis can help deal with “path convergence,” places in the network diagram where multiple paths 
converge into one or more activities, thus adding risk to the project (see figure 8.17). Monte Carlo analysis is also used as 
a risk management tool to quantitatively analyze risks (see the “Risk” chapter). 


FIGURE 8.17 Path convergence 


Resource Optimization 
Resource optimization refers to finding ways to adjust the use of resources. There are two techniques that can achieve 
this outcome. 


Resource Leveling 


Resource leveling is used to produce a resource-limited schedule. Leveling lengthens the schedule and increases cost to 
deal with a limited number of resources, resource availability, and other resource constraints. A little-used function in 
project management software, this technique allows you to level the peaks and valleys of the schedule from one month to 
another, resulting in a more stable number of resources used on your project. 

You might level the resources if your project used 5 resources one month, 15 the next, and 3 the next, or some other 
up-and-down pattern that was not acceptable. Leveling could also be used if you did not have 15 resources available and 
preferred to lengthen the project (which is a result of leveling) instead of hiring more resources. 


Resource Smoothing 


Resource smoothing is a modified form of resource leveling, where resources are leveled only within the limits of the float 
of their activities, so the completion dates of activities are not delayed. 
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Agile Schedule Development 

Agile teams attempt to keep schedule and cost stable while negotiating scope to make that happen. The 
concept of float certainly applies to agile although agile practitioners do not always use the project schedule 
network diagram. Instead, based upon the estimated story sizes and prioritization, an agile team will gather Agile 
stories for each iteration and estimate how much can be completed in a given iteration, adjusting estimates Focus 
until an average velocity is established. 


Agile Release Planning _ 


Agile projects are often divided into releases and iterations. An iteration is a short, timeboxed development period, 
typically one to four weeks in duration. A release is a group of iterations that results in the completion of a valuable 
deliverable on the project. An agile project will have one or more releases, each of which will contain one or more iterations, 
as illustrated in figure 8.18. 


10% -15% 80% - 85% 5% 
<— Schedule ——> Schedule >» <- Schedule -> 


“RED i o DR i o ae 
oe = 


Iteration 0 ' Development Releases 
iterations 


Stabilization ("Hardening") 
Pre-release Iteration 


FIGURE 8.18 Project broken into releases and iterations 


This diagram shows a single project with four planned releases. Agile teams start planning releases and iterations early 
in the project life cycle and progressively refine the planning effort multiple times as the project progresses. 

Do you remember our discussion on the backlog and product roadmap in the “Scope” chapter? While the backlog 
and the product roadmap help identify and manage project scope, they are also valuable tools that help develop and 
manage the project schedule. 

On agile projects, teams select from the top-priority backlog items to come up with their next iteration goal. Then, 
they decompose the iteration goal into user stories to get Project XYZ—Feature Flow 
the iteration plan. Planning continues by decomposing 
those user stories into tasks. While the work is being done, 
the team discusses the details of the work in the daily 
standup meetings. 


[E Totar 
In progress 
E completed 


Cumulative Flow Diagrams 


Cumulative flow diagrams (CFDs) are valuable tools for 
tracking and forecasting the delivery of value. They can help 
the project manager gain insight into project issues, cycle 
times, and likely completion dates. Basically, CFDs are 


Total Features 


stacked area graphs that depict the features that are in 
progress, remaining, and completed over time. An example 
of a CFD is illustrated in figure 8.19. 

This figure shows the features completed versus the T 
features remaining for a fictional project that is still in Apr May Jun Jul Aug Sep 
progress. The orange area represents all the planned features 
to be built. This number rose from 400 to 450 in June and 
then to 500 in August as additional features were added to FIGURE 8.19 Cumulative flow example 


Time 


219 


Schedule EIGHT 


the project. The dotted section plots the work in progress, and the striped section shows the total number of features 
completed on the project. 


Velocity 


As mentioned in an earlier section of this chapter, teams establish an average velocity, which describes how much work 
(what stories) can be completed in a given iteration. The team iteratively analyzes their actual velocity against the stories 
in the backlog to be completed, so this practice works as a planning method and as a control method. Velocity works 
like this: 
+ Before the first iteration of the project the team establishes a starting velocity. The metric is most often story points. 
This helps estimate what stories can be completed in the first iteration. 


+ For the first iteration, the team selects and builds stories from the top of the prioritized backlog based on the 
starting velocity. 


+ After the first iteration (not including iteration zero), the estimate is compared to what the team actually completed, 
and for the second iteration the team will use the actual velocity from the first iteration. They select stories from the 
top of the prioritized backlog based on this number. 


+ After several iterations the team has an average or working velocity. They will continue to select stories from the top of 
the backlog based on average velocity. They recalculate the average velocity as it stabilizes. 


35 
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FIGURE 8.20 Velocity tracking chart 
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Cautions on Story Point Estimates and Velocity È 

The use of story points is a relative estimating method that is very effective. But problems with this method can only be 
avoided if teams use it properly and good leadership skills and communications ensure that other stakeholders understand 
it. Story points in estimating and velocity in practice are strictly tailored to every team and every project. For analyzing 
performance, the progress of no two teams can be compared based on story points or velocity, and no single team can 
compare their story points or velocities from one project to the next. 


Think About It. Consider this scenario. A hybrid team is using story points to track their velocity on a rewrite 
® of a customer account management website. The team is using short iterations and demos to deliver functionality 
in a largely predictive organization. After the steering committee learned the team was using story points and 
velocity to track their progress, they focused on the weekly velocity figures. 


If the points completed did not increase each week, the team was asked to explain. Consciously or unconsciously, the 
team started to inflate their story point estimates for work. That way, they would have more points to report as complete 
each week. A screen that might have been originally estimated as three points became five. However, the points were now 
meaningless to the team since they could not compare current to past performance. Questions like "are these five new 
points or five old points?” became common wastes of time. 
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To reset the process, the team used affinity estimation to compare and reset new stories with the point value from 
previous stories of comparable size and complexity. Story point inflation was reversed, and points became useful for the 


team once more. The project manager explained the situation to the steering committee, who agreed not to focus on 


weekly velocity but to use velocity only to track actual versus planned project progress across iterations toward a scheduled 


release. The project manager no longer showed detailed velocity metrics to management but instead used graphics like the 


following burndown chart. Figure 8.21 shows project progress over 4 iterations. It turns data into information, using 
velocity but better representing project progress than would focusing on the actual velocity data. 


Outputs of Develop 


Planned vs Actual Work toward Release 1 


0 12 3 


a 


wel Planned Velocity *—Actual Velocity Planned Remaining “—Actual Remaining 


FIGURE 8.21 Progress tracking burndown chart 


ing the Plan-driven Schedule 


The Develop Schedule process results in the project schedule, the schedule baseline, schedule data, change requests, and 


updates to any related proj 


Project Schedule 
The project schedule is 


ect documents. The following sections describe these outputs. 


the result of the previous planning processes and the schedule network analysis that is performed 


as part of the Develop Schedule process. As planning progresses, the schedule will be iterated in response to risk 


management and other parts of project planning until an acceptable and realistic schedule can be agreed upon. The iterated 


and realistic schedule tl 
management plan. 


The project schedu 


hat results from this effort is called the schedule baseline, which becomes part of the project 


le includes project activities with assigned dates for each activity, and includes milestones inserted 


by the project manager or management. The project schedule may be represented in formats such as bar charts or 


network diagrams. 


The project schedul 


e can be shown with or without dependencies (logical relationships) and can be shown in any of 


the following presentations created from the schedule model, depending on the needs of the project: 


+ Network diagram 
e Milestone chart 


+ Bar chart 


(described earlier in this chapter) 
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Milestone Charts 

These are similar to bar charts (described next), but they only show major events. Remember that milestones have no 
duration; they simply represent the completion of activities. Milestones, which may include “requirements are complete” 
or “design is finished,” are part of the inputs to the Sequence Activities process. Milestone charts are good tools for reporting 
to management and to the customer. See the example in figure 8.22. 


1 Start 412/14 
2 Requirements 
gathered 412/31 
3 Design 
complete 17 
4 Coding 
complete +215 
5 Testing 
complete 43/15 
6 Implementation 
complete 04/4 
7 End +4/15 


FIGURE 8.22 Milestone chart 


Bar Charts 
Bar charts are weak planning tools, but they are effective for progress reporting and control. They are not project 
management plans. The velocity tracking chart in figure 8.20 is a bar chart. 


Schedule Baseline 

The schedule baseline is the approved version of the schedule model used to manage the project; what the project and 
team performance is measured against. On plan-based projects the baseline can only be changed as a result of formally 
approved changes. If the project can be done faster than the customer requested, there may be a difference between the 
schedule baseline and the end date required by the customer. This difference is project float. Agile projects tend to have a 
“moving baseline” for velocity but it is assumed that this will soon stabilize after a few iterations. Agile project schedules 
are normally baselined since exact scope is negotiable. 


Schedule Data Schedule data encompasses all the data used to create the schedule model, including milestones, project 
activities, activity attributes, duration estimates, dependencies, and the assumptions and constraints used in creating 
the schedule. 


Change Requests This is another planning process with change requests as an output. As the project progresses, any 
changes to the schedule may necessitate changes to other parts of the project management plan. Change requests are 
addressed through the integrated change control process. 


Project Documents Updates The process of creating a final and realistic schedule could result in updates to project 
documents including duration estimates, resource requirements, activity attributes, risk register, assumption log, and the 
lessons learned register. 


Understanding the Benefits of Different Presentation Formats 

No matter how much you know about project management, there are always questions on the exam that will be tricky if 
you have never thought about them before. The different types of schedule presentations can be one of those areas. Think 
through the next exercise. Make sure you look for anything you did not know, and organize your knowledge according to 
the exercise answers. You can get quite a few questions right on the exam if you know what each of the schedule presentations 
is used for. 
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8.6 Exercise 
Test yourself! In your Exercise Notebook, record the answers to the following questions. 


1. Under what circumstances would you use a network diagram? 
2. Under what circumstances would you use a milestone chart? 


3. Under what circumstances would you use a bar chart? 


Answer 
1. To show interdependencies between activities; to calculate the critical path; to show the length of the project 
2. To report to senior management 


3. To track progress; to report to the team 


Control Schedule 


A major measure of project (and project manager) success is the schedule baseline— 
the end date agreed to in planning and adjusted for approved changes—being met. 

Monitoring and controlling efforts and taking preventive and corrective action 

throughout the project keeps it in line with the plan. 
ect’s success as planning it well. 


changes and influencing the sources, or root causes, of the changes. 


This is a signal that the project manager and team need to evaluate it and do something 
about it rather than letting the issues and the high number of changes continue. Using 
diligence and being proactive is the key to success. 


[This is as important to the proj- 
Schedule control includes looking for the things that are causing preventable 


Example There is one person or one piece of work causing a lot of changes. 


If the project can no longer meet the agreed-upon completion date, and achieving the completion date is a critical 
factor for success of the project, the project manager might recommend the termination of the project before any more 
company time is wasted. 


Think of schedule control as protecting the hard work of all those involved in planning to make sure what was planned 
occurs as close to the plan as possible. Think of being constantly on the lookout for anything that might be affecting the 
schedule. The following are some activities that can be used to help control the schedule: 


Access the PMIS to review current work performance data and compare actual progress to what was planned. 
Reestimate the remaining components of the project partway through the project (see the following discussion). 


Conduct performance reviews by formally analyzing how the project is doing (see the Earned Value Management 
discussion in the “Budget and Resources” chapter). 


Perform data analysis (this can include earned value analysis, trend analysis, variance analysis, and what-if scenario 
analysis) of project performance. 


Confirm that critical path activities are being completed within the schedule baseline. If they are not, adjust the critical 
path by taking advantage of available float. 


Adjust future parts of the project to deal with delays, rather than asking for a schedule extension (using schedule 
compression techniques such as leads and lags, crashing, and fast tracking). 


Consider adjusting to optimize resources assigned to activities to improve the performance. 
Continue efforts to optimize the schedule. 


Adjust metrics that are not giving the project manager the information needed to properly understand performance 
and manage the project. Add new metrics if needed. 
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+ Adjust the format or required content of reports as needed to capture the information necessary to control and 
manage the project (see the Progress Reporting discussion in the “Budget and Resources” chapter). 
* Identify the need for changes, including corrective and preventive actions. 


* Follow the change control process. 


Efforts to control the schedule when the project is using a change-driven approach include: 

+ Comparing work actually completed to what was predicted to be complete within a given work cycle using an iteration 
burndown chart. 

+ Holding retrospectives to address possible process improvements. 

e Reprioritizing the backlog of work. 


+ Identifying and managing changes as they arise. 


Methods for Control Schedule 

Although the project manager did their best to understand the project well enough to estimate it sufficiently in planning, 
there are always changes that occur during a project that impacts those plans. Measuring performance on a regular basis, 
using schedule compression methods where necessary, and reestimating as needed are common methods of adjusting for 
normal changes to time management on projects. 


Measurement 

The schedule itself has a natural set of metrics with which to measure progress. Traditional EVM is a common practice on 
plan-driven projects and agile teams use velocity to constantly measure actual progress against planned, and adjust as 
needed. Agile teams also use burnup and burndown charts to measure overall project progress. 


Reestimating 


It is standard practice to reestimate the remaining work at planned times and whenever it seems prudent. This is how the 
project manager makes sure they can still satisfy the project objectives within the schedule, budget, and other project 
constraints, and adjust the performance measurement baseline if they cannot. 


Artifacts of Control Schedule 
The Control Schedule process results in work performance information, schedule forecasts, and sometimes change 
requests. For example, a change to the schedule might require additional resources or a change in scope. Such changes 
must be handled as part of the Perform Integrated Change Control process. Make sure you review this important process 
in the “Integration” chapter. On agile projects, again, it is most often scope—features and functions—that are renegotiated 
if, as usual, schedule is to be kept stable and the team is behind when measured against the plan. 

This process may also result in updates to the schedule management plan and performance measurement baseline in 
addition to project documents such as the assumption log, risk register, and lessons learned register, and changes to any 
other part of the project. 


Putting It All Together 


os 
Were you surprised at the amount of effort it takes to plan and manage a project schedule? It is the project managers’ re- 
sponsibility to create a realistic schedule and to monitor and control it. For the exam, make sure you understand the prece- 
dence diagramming method and know how estimating is done in both predictive and adaptive environments. Go through 
the Quicktest at the beginning of the chapter again to help identify any gaps in your knowledge. Review the concepts you 
are still unsure about. 


Complete the following exercises based on our library case study. 
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8.7 Exercise 

Review the list of work the project manager needs to do to create the project schedule. Here or in your Exercise 
Notebook indicate the order in which this work should be completed by placing the letter assigned to each item 
into the order table below. Also indicate which process this work describes. 


A. Each of the stakeholders or team members who are responsible for an activity will be responsible for 
determining how long the activity should take. 

B. The project manager will bring together the architect, construction team lead, librarian, and the other team 
members to review the work breakdown structure and determine the activities needed to complete the project. 
C. The project manager needs to think about who will be needed to complete the project and how to 

measure performance 

D. All the activities will be plotted onto a calendar based on the availability of the person assigned to complete it. 


E. The team will discuss each activity required and identify its predecessors and successors. 


Order Work Process Groups Model Name 
Ist 
2nd 
3rd 
4th 
Sth 
Answer 
Order Work Process Groups Model Name 
Ist ie) Plan Schedule Management 
2nd B Define Activities 
3rd E Sequence Activities 
4th A Estimate Activity Duration 
Sth D Develop Schedule 
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8.8 Exercise 


Try this exercise based on a case study using adaptive tools. 


The library software application needs to be upgraded. A backlog of requested features has been collected and 
prioritized in the following backlog. Review this list and with the information provided, draft a Product Roadmap 
with three releases. Each release should include an extra feature if the team has time (stretch goal). Be sure to 


consider the dependencies. 


Backlog 


Feature# Feature 


1 


wjloæojajaju|a |u DD 


Seow 
A E 


Map of library 

Collect patron profile information 
Allow patron to set up login id and password 
“Resume Builder” 

“Job application cover letter builder” 
Connect to popular job boards 
Search by author name 

Search by book title 

Search by magazine article title 
Ability to join a book club 

Ability to add a new book club 


Product Roadmap 


High 
priorities 


Total 
Stretch goal 


Total with 
Stretch 


Release 1 Release 2 
Feature Est. Feature 


Priority 
High 
Med 
High 
High 
Med 
Med 
Med 
High 
Med 
Med 
Med 


Dependencies 


Est. 


None 


None 


Release 3 
Feature 


Estimate (est.) 


1 story 
3 story 
5 story 
5 story 
3 story 
5 story 
3 story 
5 story 
8 story 
3 story 
5 story 


points 
points 
points 
points 
points 
points each 
points 
points 
points 


points 


points 


Est. 
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Answer 

Does your product roadmap look like this ? In parentheses is the feature number for each story. If you have variations, 
make sure that you understand the differences and think about why your version is a plausible way to approach the 
project as well as why ours is a plausible version of completing the project. 


High Map of library (1) 1 Search by book title (8) 5 Connect to first job s 
priorities board (6) 
Collect patron profile (2) 3 “Resume Builder” (4) 5 “Job application cover 3 


letter builder” (5) 


Allow patron to set up 5 Ability to add a book 5 Ability to join a book 3 


login id and password club (11) club online (10) 
a 
Stretch goal Search by magazine 8 Search by authorname 3 Connect to second job 5 
article titles (9) (7) board (6) 
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QUICKTEST 


* Cost Management 


9 Budget and Resources -Ssss 


* Earned value analysis 


(EVA) 
+ Earned value 
management (EVM) 
Introduction * Cost management plan 
e Types of cost 
Do you create a budget for your projects? Do you have practical experience managing and controlling - Variable 
project budgets? If these efforts are not part of how you manage your real-world projects, make sure - Fixed 
you read this chapter carefully and fully understand the concepts presented. rs piresi 
While managing cost (i.e., the project budget) the project manager is primarily concerned with eee ciini 
estimating, and with earned value management (EVM). A subset of budget management is material + Bottom-up estimating 
resource management since resources cost money, so must be in the project budget. Cost management + Estimate ranges 
includes estimating and uses the same estimating techniques covered in the Schedule chapter. In this - Rough order of 
chapter we explain in detail the EVM content, which is also applicable to both schedule and cost. magnitude (ROM) 
- Budget 
Think About It. A project manager has to be able to think simultaneously about the big - Definitive 
om picture as well as the details. To think holistically, it’s hard to think about cost without also + Basis of estimates 


Adaptive estimating 
* Cost aggregation 

+ Burn rate 

Progress reports 

e Reserve analysis 
Earned value terms 


© considering scope and schedule. The team uses the project budget and schedule to build the 
A project scope. Many of the same estimating and EVM methods are used for cost management 
as well as schedule management. Earned value analysis is all about how much of the project $ 
schedule and budget have been used to build the scope as compared to what was planned to 


be built and spent at a certain point in time. 


If you recall, a plan-driven project decomposes the product and project management work into are 
work packages, the artifact of which is the WBS (“Scope” chapter). The activities to build the work i ae 
packages are then sequenced into a schedule network diagram (“Schedule” chapter) where activity = BAC 
duration estimates are placed. In this chapter, we'll discuss how cost is estimated based on those - EAC 
activities. = ETG 
Agile teams have a fixed cost and time so budgeting is more straightforward. For = - VAC 
agile projects the work is also decomposed, but remember it is kept track of in a backlog. ( A ) * Formulas for earned value 
A product backlog is somewhat analogous to a WBS in this context because it should Agile EPEE 


include everything in the project. The backlog is broken down from the feature level to foan 


the story level, and then each story may be broken into tasks. Here the (agile) use of the word “task” is 
analogous to “activity” in plan-driven projects. In either case the work is being broken down so it can 
be easily understood, estimated, and assigned to resources. On exam questions, look for the appropriate 
context so you can identify the correct answer. 


Definitions Related to Budget and Resource Management 


Here is the budget-related vocabulary you will want to be sure you know for reading this chapter and 
for the exam. Vocabulary related to specific EVM metrics will be discussed in the Earned Value Man- 
agement section later in this chapter. 


Earned Value (EV) 


EV is a metric that gives the estimated value of the work that has actually been completed on the 
project to date. A project manager uses EV along with other metrics in earned value analysis to 
determine how well the project is doing compared to its performance measurement baseline (the 
scope, schedule, and cost baselines). 
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Earned Value Analysis (EVA) 


This is an analysis method that uses earned value and other metrics to evaluate how well the project is doing relative to 
what was planned to date. The previous CV example is one measure, but schedule variance (SV) can also be measured, and 
together with other measures the project manager can determine the overall project performance against the performance 
measurement baseline. 


Earned Value Management (EVM) - 
EVM is the practice of managing scope, schedule, and cost using earned value analysis to control the project. The results of 


earned value management tell the project manager what changes, if any, are needed to complete all the project § scope on 
time and within budget. Agile projects use earned value management with the qualification that some of the least critical 
scope stories may be put off to another release or a later project to meet cost and time constraints. Anywhere along the 
spectrum of development approaches, agreed quality requirements must be met. 


Cost Management Overview 


As you have come to expect, we will use PMI’s Process Groups model to help you understand the overall Cost Management 
process. 


The Examination Content Outline and Process Groups Model 

Below you will see how in the Examination Content Outline (ECO), the single budget and resources management task maps 
to the Cost Management process in the Process Groups model. Like with scope and schedule management, the Process 
Groups model has processes related to Planning and Monitoring and Control, but not to executing. This is because the 
team does the work of spending time and budgetary resources to build the scope of the product while the project manager 
monitors and controls that work—equivalent to the “manage” part of “Plan and manage budget and resources” in the ECO 
Process domain. Note that this ECO task also includes managing physical, or material, resources. 


Domain II Cost Management Domain 2.4 
Planning 
Task 5 Plan Cost Management —a Domaine 
Plan and manage budget and resources s i 
Estimate Costs Planning Delivery 
Determine Budget —' Domain 2.7 
Measurement 
Control Costs —! Monitoring Doman 2E 
Control Resources —1 & Controlling oa 


oe Think About It. Estimating is initially done during planning, and EVM is used to control costs (and resources 
a and procurement) throughout the project. As you manage costs you will also: 


a + Manage conflict and negotiate project agreements (domain I, tasks 1 and 8) 


+ Promote team performance through training and the use of emotional intelligence (domain 1, tasks 5 and 14). 


These all support value-driven delivery and cost savings. What can you add to this list of interactions between 
processes and ECO tasks? Practice thinking holistically by scanning the ECO for other tasks that work in unison with 
these. Think about how decisions around financial resources might affect procurements, project risks, and other project 
constraints. Some material resources, like equipment, for example, may be available within the organization or may be 
procured for the project. These decisions influence how the project is planned across all constraints and how work will be 
completed. If you haven’t had to deal with these concerns on your own projects, it’s easy to miss questions on the exam 
about how cost-related decisions could impact the rest of the project. 


230 


NINE Budget and Resources 


Figure 9.1 can help you visualize the cost management process from the Process Groups model perspective, which 
can help you understand, in general, cost management no matter a project 's development approach. Take time to review it 


before moving on to the rest of this chapter. 


Key 
oe Continuous change control 
* TS consistent with all 
approaches 


mange prompts a process 
"ú to be reiterated through 
si progressive elaboration 
or agile methods 


«===> Changes that cause a 
return to Initiating are rare 


FIGURE 9.1 Cost management process 


Desired Outcomes From Successful Budget and Resources Management 

Assume for the exam that project budget and resources are properly planned and managed unless information in an exam 
question indicates otherwise. This means that the following outcomes should be expected as a result of successful 
communications management: 

+ Budget strategies on the project are planned and executed according to the needs of the project. This results in few or 
no problems that cause the need to increase the budget baseline. Risk planning helps with this goal because most risks 
will have planned contingency plans and budgets built into the project budget. 

* Good servant leadership in the management of the team should have the outcome that the project has on it a qualified, 
motivated, and high-functioning team. This team will have the support and training needed to build and deliver the 
project’s deliverables at the appropriate levels of quality and within the project budget. 


Plan and Estimate Project Costs 


Besides having a plan for how costs will be managed, the project manager also 
needs to estimate costs and determine the budget. The Plan Cost Management pro- 
cess involves answering questions such as, “How will 1 go about planning cost for 
the project and who needs to be involved?” and “How will I effectively manage the 
project to the cost baseline and manage variances?” 

The project charter includes the high-level cost constraint and other available 
requirements regarding cost management on the project. Organizational process 
assets used in this process include cost data and lessons learned from previous 
projects as well as organizational standards and policies for estimating 
and budgeting. 
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Plan Cost Management 

In some organizations, cost planning may involve determining whether the project will be paid for with the organization $ 
existing funds or will be funded through equity or debt. It can also include decisions about how to finance project 
resources—such as choosing whether to purchase or lease equipment. As the project manager gets detailed estimates and 
develops the budget, calculations are used that were created for project selection (covered in the “Foundations” chapter), 
like net present value (NPV), return on investment (ROI), payback period, and discounted cash flow. With these the 
project manager evaluates whether the project is still feasible within the charter and whether the measurable project 
objectives can be achieved. 


The cost management plan can be formal or informal, but it is part of the project management plan. It may include 
the following: 

+ Specifications for how estimates should be stated (in what currency) 

* Levels of estimate precision needed 

+ Approved estimating techniques 

* Roles and responsibilities for various cost activities (e.g., estimating, tracking, reporting) 

+ Reporting formats 

+ Whether costs will include indirect costs (not directly attributable to one project, like overhead) 

e Guidelines for establishing a cost baseline to measure against 

+ Methods for documenting costs 

* Control thresholds (amount of allowable variation before the project manager needs to act) 

+ Rules for measuring cost performance 

+ Cost change control procedures 

+ Information on control accounts or other ways to monitor spending 

+ Funding decisions 


e Guidelines for dealing with potential fluctuations in resource costs and exchange rates 


Estimate Costs 
The process of estimating project costs involves estimating individual components and then aggregating all estimates into 
a time-phased spending plan (detailed next in Determine Budget). 


oe Think About It. In the “Schedule” chapter there is a checklist called “Things to Know about Estimating for the 
Exam” on page 197. Take some time now to review that list since it applies to estimating schedule and cost. It is 
Cy helpful to have those concepts fresh in your mind before continuing. 


So what costs should be estimated ? In addition to labor and material resources and training for the project, the project 
manager also estimates the following: 


© Labor costs for all project activities or tasks ® Project management activities 

è Material resources to complete activities or tasks è Physical spaces used directly for the project 

© Training è Overhead costs, as applicable 

e Quality efforts (those indirect costs like management salaries and 
a Riskefforts general office expenses) 


Types of Cost 


In the past, the exam has included questions regarding types of cost. A cost can be either variable or fixed, direct or 
indirect—and these two pairs are not mutually exclusive. For example, there can be both direct variable costs and direct 
fixed costs. 
+ Variable costs These change with the amount of production work. 
Examples Materials, supplies, wages. 
+ Fixed costs These do not change as production changes. 
Examples Rent, utilities. 
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+ Direct costs These are directly attributable to work on the project. 
Examples Team wages, training, travel and recognition expenses; project materials costs. 


* Indirect costs These are overhead costs incurred for the benefit of more than one project. 
Examples Taxes, fringe benefits, janitorial services. 


Artifacts Needed to Estimate Costs 

We all would agree wed want our estimates to be as accurate as possible. Where is the first place you would look for help 
with this? Previous, similar projects! Imagine having a repository of all the previous WBSs for similar projects, along with 
the estimates and actual costs for each activity. Can you see how that might be helpful in creating more accurate estimates 
on your own projects? Other historical project artifacts include: 


+ Resource requirements documentation * Templates and processes including those from 

* Cost and quality management plans Pas projects 

+ Scope and schedule baselines e Corporate governance 

* Lessons learned and risk registers * Marketplace conditions, commercial cost databases, 
* Policies and historical records related to estimating exchange rates, inflation, and supply sources 


Estimating Methods and Accuracy _ 


As described in the “Schedule” chapter, estimates should be created from ranges as it is very unlikely an activity’s completion 


will result in a single, exact estimated time or cost. Estimating is done using common methods like analogous, parametric, 
and three-point estimating. 


example, say someone walks into your office and asks you to estimate the total cost of a new project. The first 
question you may ask is, “How accurate do you want me to be?” Early in the project during initiating, estimates 

Or are top-down, high-level estimates. Over time, as you break down project deliverables during planning, you 
narrow the estimate range as you do bottom-up estimating. 


a Think About It. From a general perspective, these methods fall into the top-down or bottom-up categories. For 


Top-down and bottom-up estimating each have the following advantages and disadvantages: 


Top-Down (Analogous) Estimating 


Advantages Disadvantages 

* Quick + Low accuracy level 

+ Activities and material resources do not need to + Reflects limited information about the project or 
be identified key deliverables 

+ Less costly to create e Requires considerable experience to do well 

+ In initiating, provides cost constraints to evaluate * Conflicts to gain budget priorities may not have the data 
high-level project feasibility able to justify the need 

* Overall project costs can be capped for this type * Difficult for projects with uncertainty or without similar 
of estimate projects to reference 


* Does not consider differences between projects 


Bottom-up Estimating 


Advantages Disadvantages 
+ Based on detailed project and deliverable analyses * Requires that the project be well defined and understood 
+ More accurate (at the activity or task level) * Requires effort to break project deliverables into 
* Gains buy-in from the team because the team smaller pieces 
helps creates the estimates + Takes relatively more time and money 
* Provides a basis for control and management + Risk of padded estimates unless the team understands the 


use of reserves 
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Estimate Ranges The standard estimate range types are order of magnitude, budget, and definitive. Using each implies a 
particular level of accuracy. These are discussed below: 
+ Rough order of magnitude (ROM) estimate Usually made during initiating, a typical range for ROM estimates is 
-25 to +75 percent. It varies depending on how much is known about the project. 
+ Budget estimate A refinement from a ROM estimate, a budget estimate is typically in the range of -10 to +25 
percent The range is narrowed from ROM before reiterating the budget. 


+ Definitive estimate As planning progresses, the estimate should become even more refined. Some project managers 
use the range of +/-10 percent, while others use -5 to +10 percent, and this may depend on what management 
requires. 


TRICKS What you see here may be different from your experience. For the exam, make sure you understand estimating 
in ranges and that estimates become more refined as project planning progresses. Remember that organizations 


kiM] have different rules for the acceptable estimate range for an activity or the project. It is wise to estimate in a 
range, based on the level of uncertainty remaining in the estimate. 


Even the approved baseline may be expressed as a range. 


Example “$1,000,000 (-5 to +10 percent).” 


Human and Material Resource Cost Rates 

It may seem obvious that resource costs involve estimating the work of consultants, sellers, and equipment and supplies. 
Although many project managers do not have access to this information on their projects, the exam assumes a project 
manager also uses the actual cost of internal human resources when performing cost estimating. 


Estimating Costs: Final Notes 


Spreadsheets and software within the PMIS can speed up calculation and analysis and integrate finance and accounting. 
Quality, risk, and scheduling tools are useful here as well. Alternatives analysis, reserve analysis, and decision making (all 
discussed in the “Schedule” chapter) may also be used as part of the Estimate Costs process. 

The Estimate Costs process results in cost estimates and the basis of the estimates (an explanation of how the estimates 
were derived). It can also result in project document updates, such as the risk register, assumption log, and lessons 
learned register. 

Once the project manager has completed estimating costs they have the costs for each work package or story based 
on the activities needed to build them, the documentation on the basis of estimates (what are their assumptions, etc), and 
other project artifact updates like those to the assumption log and the lessons learned and risk registers. 


Determine Budget 


The project manager aggregates the total estimated costs (including estimated risk 
reserves) for the project to determine the cost baseline. An approved budget in- 
cludes that baseline plus a management reserve (more on reserves in the “Risks and 
Issues” chapter). The traditional projects ‘cost baseline is a measure of project suc- 
cess. The project manager uses it to control costs while the project work is being 
done. 

The project manager also revisits the feasibility of the project in determining 
the budget during planning. They review the business case and the benefits 
management plan. The business case may be expressed in financial terms such as 
expected return on investment (ROI). The benefits management plan can be used 


to compare the estimated budget to the business value the project is supposed to 
bring to the organization and its stakeholders. 
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Lets’ review the planning process as it culminates in getting to this point with the projects cost baseline. Here the 
project manager has done the following: 


+ In initiating, incorporated the information provided (through top-down estimating) into a project charter, which 
became a basis for planning since planning and executing must remain true to the project charter. 


+ Determined the project scope—both what is and what is not included in the project. This becomes the scope baseline. 


+ Decomposed product scope into deliverables and then smaller, more manageable pieces (like activities or tasks) for 
the purpose of estimating, assigning resources, and building that scope. 


+ Estimated time and costs for each of the product scope components. 


e Calculated the aggregate project costs for the project using the estimates for each of the product scope components 
(bottom-up estimating). Remember that materials costs may appear in line items separate from team resources 
assigned to activities. 


+ Assigned time estimates to each activity along a network diagram to help establish the project 5 critical path and the 
project schedule baseline. 


To finish the budget the project manager will include estimated risk reserves (included in the cost baseline) and 
management reserves (part of the budget but not the cost baseline; see figure 9.2). 


Future Performance Measurement 


Once risk planning is included (see the “Risk and Issues” chapter), the project manager has the projects performance 
measurement baseline: the scope, schedule, and cost baselines. We cover performance measurement in more detail in the 
following Control Costs section of this chapter. 


Adaptive Estimating Methods 


On adaptive projects the team breaks down scope using t-shirt sizing, affinity estimating, and Planning AN 
Poker*. The team uses story maps to plan releases. Refer to the “Schedule” chapter for a review of these ( A j 
concepts. A story map is analogous to a network diagram, but do not take the analogy too far. The resulting Jim 
schedules and budgets approved for traditional projects are thought to be more fixed, where a release map is no 


meant to give a general idea of how the product releases will unfold. Agile projects do tend to fix cost and time while 
varying scope, but if a customer decides to drop some features as the product is developed during early releases, this will 
inevitably affect the projects costs. Adaptive teams also use retrospectives to determine the accuracy of budget estimates 
and whether budget adjustments should be made. 


Artifacts of Determine Budget 
Two artifacts of Estimate Costs—cost estimates and the basis of estimates—are essential inputs to the Determine Budget 
process. Many of the inputs to Estimate Costs are used here as well: 


+ Cost management plan 

+ Scope baseline 

* Project schedule model 

e Risk register 

+ Existing policies on cost control and cost budgeting 


+ Resource requirements documentation (for example, for how long and at what costs for particular resources, including 
materials, supplies, and equipment costs) 


+ Agreements (regarding the purchase of services or products for the project) 
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Aggregating Costs into a Budget _ 


To prepare the budget for approval, the project manager needs to do what's called cost aggregation. To do this, they would 
pull together the costs of all activities—including risk management activities, which go into the budget as risk reserves 


(covered in the “Risk” chapter). 


Think About It. Review the following list and follow along with the Figure 9.2. Read the figure from the bottom 


up as you think about the items in this list: 


rN 1. Activity estimates are rolled up into work package estimates (see #2). 


2. Work package estimates are rolled up to control account estimates (see #3). 


3. Control account estimates track entities that cost will be assigned to (and do not affect totals). 


4. Project estimates is a total for the budget, to this point. 


5. Contingency reserves are established during risk planning. When added here, contingency reserves 


determine the cost baseline (#6). 


6. Cost baseline An estimated total cost performance measurement baseline. 


7. Management reserves are added in the final step. 


8. Cost budget is a total that includes the cost baseline + management reserves. 


Notes: 1) Estimated costs and reserves are shown aggregated at the cost budget level and depicted in figure 9.2, but 
remember contingency reserves are added at the activity level and work package levels initially during planning for risk 
management. 2) It is the management reserve (covered in the “Risk” chapter) that makes the difference between the cost 


baseline and the budget. 
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FIGURE 9.2 Aggregating costs to create a budget 


After the cost baseline and budget are estimated, the project manager may compare these numbers to parametric 
estimates or to expert judgment, or perform an historical information review, comparing their estimates to those of past, 
similar projects. For example, a general rule for a high-level parametric estimate in some industries is that design should be 
15 percent of the cost of construction. Other industries estimate the cost of design to be 60 percent of the project budget. 
The project manager needs to investigate and justify any significant differences between the project estimates and the 


reference data to ensure the estimates are reasonable and as accurate as possible. 
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Cash Flow, Financing, and Budget Reconciliation 
For the exam, a well-planned, approved budget assumes that the project manager has worked with the performing 
organizations’ finance department to ensure that cash flow planning for the organization will include expenditures for the 


project just when they are needed. The cost baseline, therefore, is time-phased. 

Example Equipment costing $500,000 is scheduled to be purchased on June 1 but the money for the purchase is not 
available until July 1. The activities dependent on that equipment will have to be moved to later points in the schedule. 
Burn rate on agile projects Are you familiar with the term “bum rate”? It is a common business metric 
referring to the rate at which an entity—in this case an agile team—is using (or losing) money. You may 
remember that on adaptive projects, teams are often stable and consistent because more value is placed on Agile 
retaining project knowledge and keeping together a team that has already developed its high-performance = 
capabilities. One advantage of stable teams is that there are consistent burn rates and simplified cost estimating. As 
discussed in the “Schedule” chapter, agile teams use velocity to help create a project schedule based on story point estimates. 
Velocity can help anticipate future budgetary issues as well. 


Think About It. A team is averaging 50 story points per month and there are 500 story points left in the backlog. 
: They would need 10 more months to complete the project. If their salary burn rate is $45,000 per month, can you 
aa estimate the cost for the 10 months? 


It is 10 x $45,000 = $450,000. Knowing this, you can look at the budget and decide if you have correctly estimated a 
budget for 10 more months of the team’s monthly salary bum rate. 


Checking with the Project Ch: 


The project budget must be reconciled with any cost constraints in the charter. If the project estimate exceeds these 
constraints, the project manager must meet with the sponsor, explain why their cost requirement cannot be met, and 
propose options to decrease costs. If that cannot be done, the project’s budget baseline must be increased. Pay particular 
attention to these last two sentences. As with the schedule, project managers have a professional responsibility to reconcile 
the budget in this way. 

When the Determine Budget process is complete, the cost baseline, including all funding requirements, is established. 
Naturally, many of the inputs to the process will be updated, for example the cost estimates, the risk register, and the 
project schedule. 


Control Costs and Resources 


Once the project cost measurement baseline and budget are complete, the 
project manager will need to continuously look for anything that affects that 
baseline even if it can cause the project to be terminated. Start this section by 
completing the following exercise and imagine how this would apply to real- 
world projects. 


Think of yourself as a detective looking for anything that can get in 
TRICKS F See g 


OF THE the way of project success. This mindset will help you select the 
pit best choice when answering questions on the exam that may seem 
to have more than one correct answer. 


For more information on controlling resources, be sure 
to read these free articles on the RMC Resources page (rmcis. 


com/rmc-resources): “Controlling Resources Checklist,” 
“Resource Responsibilities for the Project Manager,” and A Yj 
“Resources and the Project Budget.” RMC RESOURCES 
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9.1 Exercise 


This is an important topic so be sure to take your time to think this through. In your Exercise Notebook, list the 


actions a project manager may take to control costs and resources. 


Answer 


Follow the cost and resource management plans for how to control costs 
Tailor control activities to the needs of the project 


Consider policies, procedures, tools, and reporting templates and formats related to controlling costs 
(selected from organizational process assets during planning) 


Measure project performance and compare it against the plan 
Determine if variances require change, including preventive and corrective action 
Request changes 


Implement approved changes 


Prevent unnecessary changes 

Look for the root cause of factors causing costs to rise 
Conduct earned value measurement 

Conduct reserve analysis (related to risk) 


Aggregate data, analyze it, and produce reports 


Managing Change 


Controlling costs is an important responsibility for project managers, but you must also understand and plan for potential 
budget variations. No matter how well the project manager plans in a predictive environment, change is inevitable. In 
adaptive environments changes to scope are more frequent so agile teams have built in methods to handle changes 
throughout the project and meanwhile try to preserve the original budget if possible. Change management is covered in 
more detail in the “Integration” chapter. In any case, it should go without saying that changes to the cost baseline must be 


made formally with approval. 


Think About It. Your team worked overtime to complete a new feature for an upcoming sponsor demo. 
While the new feature was completed on time, the overtime work means your monthly budget goal for 
= payroll will be missed. As the project manager, you weighed the value of this through an analysis of benefits 
and costs. The benefit outweighed the cost, so you approved the overtime. You need to revisit this decision 


when forecasting the future of the project. Was this months higher payroll atypical or has your team consistently 


needed overtime hours to complete the necessary work? Should you adjust the budget for future months or adjust the 


schedule to avoid unnecessary overtime? 


Think About It. What would happen if a team member suddenly realizes the materials they need to finish 


a an activity are out of stock? More will have to be ordered. Time will be lost to waiting for the materials and 


a last-minute order is likely to be more costly than if the materials had been better controlled. 


There can be many unplanned scenarios that impact the project budget, and additional costs may be unavoidable. As 
the project manager, you should look for these situations, anticipate the potential risks, and plan ahead. You will never be 
able to foresee everything, but if you try to imagine the unplanned costs on your project, you will have a much easier time 


planning and managing a realistic budget. 
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Progress Reporting 

Through earned value measurement, the project manager analyzes data about project progress to help control the schedule 
and costs and to assess whether the project is on track (described later in this section). Progress reports convey information 
based on this data analysis method. Asking team members for percent complete of their deliverables may be used by some 
project managers but this does not convey a realistic estimate of progress. They can carefully track progress using percent 
complete at the work package or story level but the cost and schedule estimates for the work package or story should also 
be factored in. 

In terms of data gathering, an often-cited metric on traditional projects is that 80 hours is a small 
enough work increment to track progress against and still have accurate data. For the exam, remember that 
traditional projects using proper project management make use of a WBS, and activities to produce work 
packages are broken down to an appropriate level for controlling. Material resources like equipment 
usually appear in the budget as separate line items, and may even be related to costs detailed in procurement 
documents. For more information on the relationship of costs and resources, see the “Resources on 
Projects” article on the RMC Resources webpage. ah 

On agile projects, data gathering and analysis will be centered around the backlog and how many (A ) 
features have been developed to date relative to what was planned. Story points by iteration are tracked for Orme 
the team’s use and burnup and burndown charts are used for both the team and other stakeholders. Review 
these types of reports in figure 6.6 in the “Build and Support Team Performance" chapter. 


Reserve Analysis 

Remember the contingency reserves that get factored into the cost baseline to address known risks? Reserve analysis allows 
you to identify and apply lessons learned in controlling costs. Part of cost control is analyzing where contingency reserves 
are still necessary or where new reserves are required. Both of the following examples would require a formally approved 
change request. 


Example A project team identifies a highly ranked risk and sets aside a contingency reserve to address it. If the risk 
does not occur and is no longer a threat, the contingency reserve can be removed from the cost baseline. 

Example A risk review on a project identifies new risks, which could lead to a decision to increase the contingency 
reserves. 


Think About it. A formally approved change request is also required to move management reserve funds 
into the cost baseline for a similar purpose. It may also be necessary to reassess the amount of management 
reserve that was set aside to address unknown risks. This difference between contingency reserves (for 
identified risks) and management reserves (for unknown risks) is an important distinction that can help you 
get more questions right on the exam. We have mentioned this distinction earlier in this chapter and discuss 
it again in the “Risks and Issues” chapter. 


Earned Value Management 
As a project manager, you manage project performance and you account for that performance to stakeholders by comparing 
planned to actual results. This is the essence of earned value management, which includes earned value analysis. Earned 
value analysis is a data analysis method used to evaluate project performance against the entire performance measurement 
baseline (the scope, schedule, and cost baselines). Earned value analysis results indicate whether there are any potential 
deviations from the performance measurement baseline. 

Earned value analysis can be used to forecast future performance and project completion dates and costs. This 
information is conveyed to stakeholders through reports in meetings and other communication methods. 
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Formulas for Earned Value Analysis 


As of this book’s publication, very few questions on the exam contain formulas. Nevertheless, you should go through this 
section carefully. Even if you get few or no formula questions, earned value analysis is on the exam and understanding this 
content will help you get those questions right. Of course, memorizing the formulas we specify in this section will help you 


with questions requiring you to calculate formulas, even if there are not many. 


Are you worried about it? Don’t be. We are going to make it easier. First, think about this: How valuable would it be 
to know how your project is really going? Could you sleep better at night? Would you be able to spend your time in more 
productive ways than worrying? Keep the benefits of the earned value analysis method in mind as you read this section. 


oo *Think About It: Terms to Know. Here are the earned value terms you need to know. 


E5 Acronym 
PV 


EV 
AC 
BAC 
EAC 
ETC 


VAC 


Term 


Planned value 
Earned value 
Actual cost 


(total cost) 


Budget at completion 
(the cost baseline) 
Estimate at completion 


Estimate to complete 


Variance at completion 


Interpretation 


As of today, what is the estimated value of the work planned to 
be done? 


As of today, what is the estimated value of the work actually 
accomplished? 


As of today, what is the actual cost incurred for the work 
accomplished? 


How much did we budget for the total project effort? 


What do we currently expect the total project to cost (a 
forecast)? 

From this point on, how much more do we expect it to cost to 
finish the project (a forecast)? 

As of today, how much over or under budget do we expect to be 
at the end of the project? 


Think About It: Formulas and Interpretations to Memorize. On the exam, you may not need to perform 
many calculations but you must understand what the numbers mean. Therefore, you should know and understand 


@ all the formulas in the following table. 
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Name Formula 
Cost variance (CV) EV-AC 
Schedule variance (SV) EV-PV 
= performance index EV 
(CPI) AC 
Schedule performance EV 
index (SPI) PV 


Estimate at completion 
(EAC) 


NOTE: There are many 
ways to calculate EAC, AC + Bottom-up ETC 
depending on the assump- 

tions made. Notice how the 

purpose of the formulas 


really is to create forecasts 


BAC 


based on past performance CPI 


of the project. Exam 
questions may require you 
to determine which EAC 
formula is appropriate. Pay AC + (BAC - EV) 
attention to the information 
provided in the question. It 
will help you determine 
which formula to use. 


ac (BAC-EV) 


(CPIC x SPIS) 


To-complete performance 
index (TCPI) (BAC - EV) 
(BAC-AC) 

Estimate to complete 

(ETC) 

NOTE: You can determine EAC -AC 

ETC by either using the F 
formula listed here or 

reestimating the cost of the Reestimate 

work remaining. 

Variance at completion 

BAC - EAC 


(VAC) 
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Interpretation 


Negative is over budget; positive is under budget. 
Negative is behind schedule; positive is ahead of schedule. 


We are getting $ 
are or are not being used efficiently. Greater than one is good; less 


worth of work out of every $ 1 spent. Funds 


than one is bad. 


We are (only) progressing at 
planned. Greater than one is good; less than one is bad. 


percent of the rate originally 


As of now, how much do we expect the total project to cost? 


$ C 


This formula calculates actual costs to date plus a revised estimate 
for all the remaining work. It is used when the original estimate 
was fundamentally flawed. 


This formula is used if no variances from the BAC have occurred 
or if you will continue at the same rate of spending (as calculated 
in your cumulative CPI or based on the trends that have led to the 
current CPI). 


This formula calculates actual costs to date plus remaining budget. 
It is used when current variances are thought to be atypical of the 
future. It is essentially AC plus the remaining value of work to 
perform. 


This formula calculates actual to date plus the remaining budget 
modified by performance. It is used when current variances are 
thought to be typical of the future and when project schedule 
constraints will influence the completion of the remaining effort. 
So for example, it might be used when the cumulative CPI is less 
than one and a firm completion date must be met. 


This formula divides the value of the work remaining to be done 
by the money remaining to do it. It answers the question “To stay 
within budget, what rate do we need to meet for the remaining 
work?” Greater than one is bad; less than one is good. 


How much more will the project cost? 


This formula calculates the total project cost as of today minus 
what has been spent to date. 


Reestimate the remaining work from the bottom up. 


How much over or under budget will we be at the end of the 


project? 
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The following should help solidify your understanding about CV, SV, CPI, and SPI: 


+ EV comes first in each of these formulas. 


* Wit is a variance “ainerence;, me rormiuia is tv minus AL or rv.~ 
e Ifit is an index (ratio), the formula is EV divided by AC or PV. 
¢ Ifthe formula relates to cost, use AC. 

+ Ifthe formula relates to schedule, use PV. 

+ For variances interpretation: Negative is bad (J) and positive is good (S). 


Example A -200 cost variance means you spent more than planned @ (are over budget). A -200 
schedule variance means you are behind schedule @. This also applies to VAC. 


+ For indices interpretation: Greater than one is good Q) and less than one is bad (v). Remember, this only 
applies to CPI and SPI. The opposite is true of TCPI. 


Understanding Earned Value Terminology 
People often incorrectly answer exam questions requiring them to simply interpret earned value terms without having to 


calculate formulas. This section is an opportunity to help you get those questions right. 


Think About it. Sometimes thinking about things in a different way can give you that “aha" moment when 
everything falls into place. Think about the following bulleted lists and figure 9.3. Together they illustrate the 
terminology to help you see it from another angle. Then, if you are still uncomfortable with earned value concepts 
put it aside for now. However, come back another day and review all the content from the “Earned Value 

Management” section of this book. Sometimes new information takes a bit of extra effort and this area is certainly in 

that category for many students. 

Planned value (PV) and actual cost (AC) look backward at what has been done on the project: 

+ P V: What is the expected value of work done at this point in the project (according to the plan) ? 


+ AC: What has the actual cost been on the project to this point? 


Budget at completion (BAC), estimate to complete (ETC), and estimate at completion (EAC) look forward at 
the project: 
+ BAC refers to the projects currently approved budget. It is a known quantity indicating what the end cost of the 
project would be if everything went according to plan. 


+ ETC and EAC forecast future performance based on what has actually been done on the project, considering 
variances from the plan the project has already experienced. 


+ ETC is an estimate of how much more the remainder of the project will cost to complete. 


+ EAC indicates what the total project cost is forecasted to be. 


Original plan l As of today 


PV L BAC 
Original spending plan 


AC 
Actual spending 


ETC EAC 
Forecast spending plan 


FIGURE 9.3 Earned value concepts by looking backward and forward on a project 
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Earned Value in Action 
Earned value is an effective tool for measuring performance and determining the need to request changes. The following is 
a sample team conversation on this subject. 

The project manager calls a team meeting and says, “We are six months into this million-dollar project, and my latest 
analysis shows a CPI of 1.2 and an SPI of 0.89. This means we are getting 1.2 dollars for every dollar we put into the project, 
but only progressing at 89 percent of the rate originally planned. Let’s look for options to correct this problem.” 

The network specialist suggests that she could be removed from the project team and replaced with someone less 
expensive. The IT coordinator suggests either removing the purchase of new computers from the project or telling the 
customer the project will be two weeks late. 

The project manager looks at the network specialist and says, “It would sadden me to lose you, and your suggestion 
would improve costs but not schedule. You are the company’s best network specialist. Someone else would not be as 
proficient as you in completing the work.” To the IT coordinator’s suggestion, the project manager responds that canceling 
the new computers would save money but not time. “Let’s focus on time.” 

Another team member suggests that since the project is doing well on cost, the project manager could bring in another 
programmer from the IT department to work on the project to get the next two activities completed more quickly. 

The project manager says, “That sounds like the most effective choice in this situation. Let’s see if we can find someone 
who will improve performance, at the lowest cost. Thanks for your help.” 


Earned Value Analysis Practice 
The best way to learn the earned value analysis technique is to use it. The following exercises are designed to give you a 


chance to practice both calculations and interpretation. Earned value questions on the exam have generally required fewer 
calculations per question than these exercises. 


9.2 Exercise 

The cost performance index (CPI) and the schedule performance index (SPI) can be charted each month to show 
the project trends. Based on the diagram, would you be more concerned about cost or schedule if you were taking 
over this project from another project manager? Write the answer in your Exercise Notebook. 


1.5 ~ 
1.3 4 
SPI 

bE CPI 
0.9 ~- 
0.7 T T T T 1 

Ist 2nd 3rd 4th 

Qtr Qtr Qtr Qtr 
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Answer 
You should be more concerned about schedule. The data in the chart is historical. Ihe last, most current 
measurement was in the fourth quarter, which shows both SPI and CPI being above one (good). As of the fourth 


quarter, the SPI is lower. An easy way to answer performance index questions that ask whether cost or schedule 
should concern you most is to pick the option with the lowest index. 


9.3 The Fence Exercise 


You have a project to build a new fence. The fence has four sides equal in length. Each side is to take one day to 
build, and $ 1,000 has been budgeted per side. The sides are planned to be completed one after the other. Today is 
the end of day 3. 


Using the information in the project status chart, calculate the following in your Exercise Notebook. Interpretation 
is important on the exam. Can you interpret what each answer means? 


LPV= 5. CV= 9. EAC= 
2. EV= 6. CPI= 10. ETC= 
3.AC= 7. SV= I.VAC= 
4. BAC= 8. SPI= 


Project Status Chart 


Activity Day 1 Day 2 Day 3 Day 4 Status End of Day 3 

Side 1 Shere F Complete, spent $1,000 
Side 2 S------- PF —F Complete, spent $1,200 
Side 3 PS-S—PF 50% done, spent $600 
Side 4 PS------ PF Not yet started 


Key S = Actual Start, F = Actual Finish, PS = Planned Start, and PF = Planned Finish 
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Answer: The Fence Exercise 


What Is: Calculation Answer Interpretation of the Answer 
1. PV $1,000 plus $1,000 plus $1,000 $3,000 We should have done $3,000 worth of 
work. 
Da EV Complete, complete, and half $2,500 We have actually completed $2,500 
done; or $1,000 plus $1,000 plus worth of work. 
$500 
3. AC $1,000 plus $1,200 plus $600 $2,800 We have actually spent $2,800. 
4, BAC $ 1,000 plus $ 1,000 plus $ 1,000 $4,000 Our project budget is $4,000. 
plus $1,000 
CV 2,500 minus $2,800 -$300 We are over budget by $300. 
6. CPI 2,500 divided by $2,800 0.893 We are only getting about 89 cents out 
of every dollar we put into the project. 
qs SV 2,500 minus $3,000 -$500 We are behind schedule. 
SPI 2,500 divided by $3,000 0.833 We are only progressing at about 83 
percent of the rate planned. 
9. EAC 4,000 divided by $0,893 $4,479 We currently estimate that the total 
project will cost $4,479. 
10. ETC 4,479 minus $2,800 $1,679 We need to spend an additional $1,679 
to finish the project. 
Hd, VAC 4,000 minus $4,479 -$479 We currently expect to be $479 over 


budget when the project is completed. 


Did you select the correct EAC formula? If not, did you miss information in the question that could have guided 
you to the correct formula? In this example, side 2 cost $1,200. Side 3 is SO percent complete and has cost $600. 
This suggests a trend that indicates side 4 is likely to cost $1,200 when complete. When there is a trend and no 
other information to indicate the trend will not continue, it’s most appropriate to use the BAC/CPI formula. 


Understanding the meaning of earned value analysis calculations is as important as knowing how to calculate them. 
Expect questions on the exam such as: 


Example “The CPI is 0.9, and the SPI is 0.92. What should you do?” 


The data show the project as both over budget and behind schedule (J). You need to interpret this and other data in 
the question and then determine which choice would address the issue(s) described. 


9.4 Exercise 


What is the SPI if the CV is $10,000, the SV is -$3,000, and the PV is $100,000? Write the answer in your 
Exercise Notebook. 
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Answer 

To find the SPI here, you need to perform two calculations. The formula for SPI is SPI = EV/PV. We know what the 
PV is, but we don’t know the EV. Luckily, we can figure it out using the information given in the question. We’re 
given the SV and PV, so we can use the following reverse formula to determine EV. 


Reverse formula: EV = SV + PV. 

EV = $3,000 + $100,000 = $97,000. 

Now we can plug the PV and EV into the SPI formula as follows: 
SPI = EV/PB = $97000/$ 100,000 = .97 


9.5 Exercise 
What is the AC if the CV is $10,000 and the EV is $97,000? Write the answer in your Exercise Notebook. 


Answer 
Answer. The CV is $10,000 and the EV is $97,000. With Known formula: CV = EV - AC 
this information, we can determine the AC by using the 
formula CV = EV - AC. We first plug the information we $10,000 = $97,000-AC 


know into the formula. 


To solve for AC, we need to get AC alone on one side of the $ 10,000 + AC = $97,000 - AC + AC 
equation. First, add AC to both sides of the equation: 
$10,000 +AC = $97,000 


The -AC and +AC on the right-hand side of the equation $10,000 + AC - $10,000 = $97,000 - $10,000; 
canceled each other out. But we still need to isolate AC on 
the left-hand side of the equation. To do this, we’re going to AC = $87,000 


subtract $ 10,000 from both sides. 


Summary: Earned Value Analysis and Managing Costs 
Whew! You made it. In summary, earned value analysis enables the project manager and team to identify and analyze 


trends in performance and variances. The information gleaned from earned value analysis allows the project manager and 
team to know how the project is performing at a given point in time and to report on this performance and also provide 
forecasts for the future of the project. Indications may require action to bring the project in line with what was planned, or 
formally approved changes to the performance measurement baseline, which may require additional funds for the project. 

Control Costs also includes monitoring the use of contingency reserves to ensure the amount of reserves remaining 


is adequate. 


Putting It All Together 


RS RS EE 
Did you recognize the estimating tools that were also used in the “Schedule" chapter? The project manager uses estimating 
tools to create the budget for the project. Remember that meeting the cost baseline will be a measure of project success, so 
the budget should be in a form the project manager can use to control costs while the work is being done. During Monitor- 
ing and Controlling, the project manager uses earned value measurement to measure project performance against the per- 
formance measurement baseline. 

For the exam, make sure you understand the difference between the different types of reserves (contingency vs. 
management). You may get 1-3 questions on the exam that require you to use a formula. It’s best if you at least know 
formulas for SV, CV, CPI, and SPI, and understand what those formulas are measuring. 
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Revisit the Quicktest at the beginning of this chapter. Do you still have gaps in your knowledge? Go through the 
chapter again to review the areas you are still unsure about. Then complete the following chapter review. 


9.6 Exercise 


Read the following case study and review the table to see some examples of what the project manager will do 


during each of the Cost Management processes. 


The city council reviewed a high-level recommendation for the new library (considered the charter for this project). 
The project manager (PM) reviews the recommendation to plan and develop a more detailed cost estimate along 


with a schedule. 


e The (PM) knows that talking with the architect and construction team leader will help formulate 


cost estimates. 


e Understanding the size and interest rate of the debt will factor into needed funds and scheduling urgency. 


e Talking with the mayor will determine how and when to effectively report progress against the budget as 


the mayor will have final signoff on the budget. 


e The PM will ask for clarity on spending authorizations and change orders. 


e Reviewing results from the city’s last building project will provide insights into costs, risks, and 


potential resources. 


e The city manager will help with reviewing and controlling the budget, as this manager will be responsible 


for project procurement. 


e To track costs, the PM will use the city’s financial reporting system, recording all expenditures within a 


month of their paid dates. 


e The PM will create monthly financial reports of expenditures and earned value. 


+ Any unexpected costs or change orders, over the city authorization policy covering the PM, must be 


approved by the city manager or mayor. 


Cost Process Examples of the PM’s work 


Plan cost 
management 


Estimate costs 


Determine budget 


Control costs 


Plan to talk with architect and head of construction about costs 

Plan to talk with major about frequency of reporting expenditures 

Review the lessons learned from the prior city building project 

Review the expected debt amount with associated interest payments 

Learn about PM’s authority for expenditures and changes to budget 

Get access to city financial system 

Talk with involved stakeholders; review price estimates of needed resources 

Get estimates for several completion dates to compare the time vs. cost considerations 
Present two different budget options to the city council for approval, answer questions 
as needed. 

After council budget selection, prepare the final budget and schedule for the city manager to 
review. Adjust as needed and get signoff. 

Enter expenditures into city financial system within one month of payments. 

Monthly reporting of total expenditures, including earned value analysis. 


Extra expenditures over PM authorization must be approved by mayor or manager. 
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9.7 Exercise 


Ulis exercise uses agile processes for the library case study. Read the scenario below and then complete the exercise 
by writing down the meanings of the given terms. Look up any terms for which you do not know the meaning, and 
do write them down. Writing them will help you learn them better than just reading them will. 


For the first set of releases, a team of 5 product developers will be assigned for a period of 6 months (besides the 
product owner and project manager). Their goal will be to offer as many features to library patrons as can be 
released in 6 months, based on the product owners (head librarians) priotity and other stakeholder feedback. 


e The team will work in two-week iterations with releases every quarter. 


e The PM will track team velocity and report which features patrons value most, compared with the time 
required to create them. 


e At the end of the 6 months, the PM will present accomplishments to management along with the product 
owner’s recommendation for next steps. 


Hands-on: Define the following terms, either here or in your Exercise Notebook. 


Term Definition 
Release 

Feature 

Product Owner 

Iteration 


Velocity 


Answer 
The wording of your answers may not match these exactly, but should be substantively the same. 


Term Definition 

Release A version of the product that is useful to the user and that can be delivered 

Feature A particular, defined aspect of the product that is useful to the user. 

Product Owner The person who decides on the priority of feature development based on expected 
value to users and cost and time to complete. 

Iteration A timebox used to complete work on a product (for example, a “two-week iteration”). 

Velocity A calculated rate of work completed per iteration, usually measured in story points. 
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Introduction 


Take a moment to think about how quality is handled on your projects. If you do not currently use a 
quality management plan this could be a difficult topic for you on the exam. This chapter will help you 
understand quality and its role in the project management process. In any organization, senior manage- 
ment is responsible for promoting an organizational approach that supports quality efforts. Team 
members must inspect their own work. For the exam, assume there is a quality department that helps 
determine quality management methods the project manager and team are required to follow. 

Organizational process assets (OPAs) are often available in the form of templates and documented 
procedures and quality requirements. Within the quality constraints already given, the project manager 
and team must tailor their practices to the needs of the project. 

Quality must be planned in and the quality plan must be executed against, reviewed, and changed 
as needed. Then, the results of the work—the deliverables—should meet the product requirements. 
Testing should be done before submitting the work to the customer for approval. 


With this in mind, let’s start with some basic definitions related to quality. 


Definitions Related to Quality 

The definition of quality is the same for both predictive and adaptive environments. All stakeholders 
must be represented in the requirements-gathering process. This makes the requirements-gathering 
effort, the requirements documentation, and the project scope baseline very important to the quality 
management effort. 


Quality 
Quality is the degree to which a project and the components of its product fulfill requirements. 
Nothing more, nothing less. Memorize this definition; it may help you get more questions right on 
the exam. 

Here is an example of an issue with quality requirements. Imagine a project in which a large group 
of truck drivers are required to use tablets with touch-sensitive screens. Prior to fleet deployment and 
during the test process, the project manager received comments that no matter how much the drivers 
tapped on the screens, nothing would happen. After some discussion with truck drivers and software 
engineers, the project manager realized the truck drivers’ hands were too rough and calloused for the 
touchscreens to work correctly. Here, the requirements were gathered and initial development had 
been done with the product owner alone, who lacked direct experience with drivers. The drivers would 
have been able to provide insight on their use of the technology during requirements gathering. 

Organizations and project managers determine how to approach the management of quality. 
Ideally, this means planning quality standards and processes into projects and their products. The 
quality process generally involves a range of practices. This includes following the established processes, 
and inspecting deliverables to ensure they meet quality standards before meeting with the customer to 
get validation and offer delivery. Along the way lessons are learned, and preventive or corrective action 
may be taken on a process or deliverable. Quality processes and standards may be updated upon review 
of how well they are working to bring about the desired product or service features. 

If asked, “Is it better to plan in quality or to inspect to find quality problems?” almost everyone 
will answer correctly that it is better to plan in quality. Exam questions focus on situations to see if you 
know how to apply this knowledge. 


QUICKTEST 


Definition of quality 
Quality Management 
process 

Prevention over 
inspection 

Continuous improvement 
Just in time (JIT) 
Quality metrics 

Mutual exclusivity 
Probability 

Normal distribution 
Statistical independence 
Standard deviation 
Interviews, brainstorming, 
benchmarking 
Cost-benefit analysis 
Cost of quality 
Marginal analysis 
Logical data models 
Mind mapping 
Prioritization matrix 
Test and inspection 
planning 
Checklistsand 
checksheets 
Cause-and-effect 
diagrams 

Scatter diagrams 
Histograms 
Alternatives analysis 
Design of experiments 
Process, root cause, 
failure analysis 
Multicriteria decision 
analysis 

Affinity diagrams 
Audits 

Design for X 
Statistical sampling 
Questionnaires and 
surveys 

Project performance 
reviews 

Inspection 

Control charts 

Cost of change 
Frequent verification and 
validation 

WIP and cycle time 
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Example Hie project manager finds that one of the team members has created their own process for installing 
hardware. What should the project manager do? If this were an exam question, beginning project managers might choose 
a response that relates to thanking the team member for the effort. More experienced project managers might select a 
choice that relates to finding out ifthe process was a good one. The most experienced project managers, who also understand 
these quality processes, select the choice that relates to investigating the quality management plan to determine if a standard 
process should have been followed. 

In an adaptive environment a project manager would likely capture quality requirements and acceptance =, 
criteria in user stories. As user stories are prioritized, quality efforts will be planned in more detail for (A ) 
upcoming releases and iterations. Short, time-boxed iterations ensure frequent opportunities to identify and P mA 
rectify quality issues through daily standups and retrospective meetings. Focus 


Definition of Done 

Agile teams define what “done" looks like throughout the project. They decide on definitions of done at the project, release, 
and story levels. The project level is roughed out based upon how much time and money there is to complete the project. 
Requirements (or product functionality increments) are prioritized at this high level. A release map is created based on 
how many releases are needed to get to the desired level of functionality. Releases are populated with stories, which 
represent functionality decomposed into smaller, more manageable pieces. If you think of the handwritten “story card” 
image, the definition of “done” is written on the back of the card (even though in reality story cards are now often created 
electronically). 

Remember that in adaptive environments requirements may change frequently so the project team reviews and 
revises definitions of done on a regular basis. Here is an example of definitions of done using our earlier example of a 
project to produce touchscreen tablets for truck drivers: 

+ Story The two stories that make up feature b have been developed and integrated, documented, tested, and accepted 

by users in the field. 


* Release For release 1, a working prototype touchscreen tablet has been tested and accepted by users in the field, 
including features a, b, d, and g. 


+ Project A working touchscreen tablet has been tested and accepted by users in the field and passed on to operations 
for manufacture, with features a, b, d, g, k, t, x, and y. 


Grade 

Different from quality, grade refers to a general classification of a product like the strength of concrete (e.g. how much 
weight can it hold) that can be used for various technical specifications (e.g., foundation of a building or sidewalk). You 
may see a situational question on the exam that uses the term “grade” in discussing quality so do not confuse the two. 

Example A low grade of concrete that supports limited weight and has zero defects might be sufficient for a project 's 
needs as long as it meets the established quality requirements (for example, a small basketball court in a playground that 
just needs to hold the weight of human foot traffic). It is not necessary to spend more on materials that will hold more 
weight than requirements call for. Similarly a high grade of concrete intended to sustain more weight could be of 
unacceptable quality if it is mixed, poured, or cured to low standards or otherwise fails to meet established quality metrics. 


Think About It. Imagine a project to build a stadium. The concrete part of the work is two-thirds done when the 
buyer arrives one day and tests the strength of the concrete. The buyer finds that the concrete does not meet the 
requirements for strength that are clearly stated in the contract. You can imagine the problems when the buyer 
says, “Rip out the concrete; it is not acceptable.” Whose fault is this? Why did this occur? 


Could we say it is the buyers fault for not testing the concrete sooner? You might argue that case, but isn’t the real 
fault with the seller for not selecting the right grade of concrete and ensuring the quality of the finished deliverable 
before meeting with the customer to validate it? Where was their quality plan? They should have planned for when and 
how they would confirm they had met this requirement. Lack of attention to quality in this scenario needlessly added 
considerable risk to the project, which resulted in rework and additional expense. 
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Here is something else to consider. Have any of your customers ever said one of your deliverables was not acceptable, 
even though they had not provided you with a definition of what was acceptable? It is important to know—in advance— 
what acceptable quality is and how it will be measured on the project. You can then determine what you will do to make 
sure the project meets those requirements. It is the project manager’s responsibility to make sure quality is defined in the 
plan for each deliverable, otherwise there will be unclear acceptance criteria, such as “the customer likes it.” Performing the 
quality management process well helps the project manager avoid many issues on the project. 


Gold Plating 


Do you remember a time on a project when one of your team members delivered more than what was needed? Can you 
think of a time when you’ve had trouble keeping a project from producing a palace when all you needed was a garage, for 
example? Gold plating refers to giving the customer extras (extra functionality, higher-quality components, extra scope, or 
better performance). Gold plating is often the team’s impression of what is valued by the customer, and the customer might 
not agree. Since most project teams have difficulty meeting the project objectives, all available effort should go into 
achieving those objectives, instead of into gold plating. 

Sometimes gold plating is not planned, but rather arises out of a team member’s efforts to do their best. The project 
manager must be on the lookout for team members providing more than is required for the project. 


Prevention over Inspection 
Is it better to inspect work to find problems or to prevent them in the first place? Which takes less effort and is less costly? 


Remember that quality must be planned in, not inspected in! You may see exam questions that test your understanding 
that failure to plan quality into a project will lead to problems later in the project. 


Continuous Improvement 
Continuous improvement involves continuously looking for ways to improve the quality of work, processes, and results. 


Within an organization it can include analysis of how quality management is planned and utilized on projects. There are 
several approaches to continuous improvement relevant to the exam. 

+ Kaizen The terms “continuous improvement” and “Kaizen” are taken to mean the same thing on the exam; however, 
in Japan, Kaizen means to alter (kai) and make better or improve (zen). Kaizen is a general term, while continuous 
improvement is a quality movement. In the United States and most of Western Europe, continuous improvement 
focuses on major improvements. In Japan, the emphasis is on smaller improvements. 

+ Total Quality Management (TQM) TQM encourages companies and their employees to focus on finding ways to 
continuously improve the quality of their products and their business practices at every level of the organization. 

+ Six Sigma Sigma (another name for standard deviation) indicates how much variance from the mean has been 
established as permissible in a process. This is a methodology for achieving organizational process improvement and 
high levels of correctness with extremely reduced variances. The higher the sigma, the fewer deviations (or less 
variance) in the process. The level of quality required by an organization is usually represented by 3 or 6 sigma. 


Just in Time (JIT) _ 


JIT means having suppliers deliver resources just before they are needed, thus decreasing inventory to nearly zero and 
decreasing unnecessary cost. A company using JIT must achieve a high level of quality in their practices; otherwise, there 
will not be enough materials or equipment to meet requirements because of waste and rework. A JIT system forces 
attention on quality as well as schedule. 
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Quality-related PMI-isms. The exam may test your understanding of the need to satisfy project requirements 
as opposed to giving the customer extras to “make them happy." Know the following PMI-isms to answer exam 


questions correctly: 
* Quality means meeting requirements, not adding extras. 
+ All product developers must know the quality standards and metrics to be used on the project. 
* Quality should be checked before an activity or work package is completed. 
* Quality should be considered whenever there is a change to any project constraint. 
+ Some quality activities may be performed by a quality department. 
+ The project manager should: 
/ Determine the metrics to be used to measure quality before project work begins. 
/ Define project quality management processes and plan for continuous improvement. 


/ Recommend improvements to the organizations standards, policies, and processes, which are expected 
and welcomed by management. 


/ Ensure that authorized approaches and processes are followed. 
/ Ensure the quality standards and processes on the project are adequate to meet product 
quality requirements. 


Overview of Planning and Managing Quality 


The following references indicate that Quality Management in the predictive Process Groups model is represented by Plan 
and Manage Quality of Products/Deliverables in the Examination Content Outline (ECO). In addition, when managing 
procurements, you will need to ensure that the buyer and seller have the same understanding of the quality process. See the 
“Procurement” chapter for more information. 


Domain II Quality Management Domain 2.4 
Planning 
Task 7 Plan Quality Management — Planning Domain 2.6 


Plan and manage quality of products/deliverables 


Manage Quality — Executing Delivery 
Control Quality — Monitoring Domain 2.7 
& Controlling Measurement 
Domain 2.8 
Uncertainty 


Think About It. Can you see how other tasks from domain II, such as stakeholder engagement and 
communications, can affect quality management? What if two team members disagree on how to approach 
building a deliverable? The quality management plan needs to reflect the best, agreed-upon, and bought-into 
approach. Skills such as conflict management and team leadership from domain I are invaluable to come to the 
best solution. Negotiation and team-building skills (also from domain I) support the best quality management 
plan and overall quality control. Take time now to review the ECO and think about these connections. 


Here is an example to help you commit your understanding of quality for the exam to memory: 

Example A student in one of RMC’s classes looked out the window and noticed someone painting the limestone of 
an old building white. The student said, “That is not quality!” Let’s think about this for a moment. Why would painting the 
limestone white not be considered “quality ”? The student's issue was that the wonderful old stone was being painted instead 
of being cleaned. This was a disagreement with the requirements, not the quality of the work. If the painting contract 
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required the painter to use a certain paint and follow painting standards, and he was doing so, the work was meeting the 
quality requirements. 


Figure 10.1 shows the Quality Management process from the Process Groups model perspective. This figure and the 
following discussions of Plan, Manage, and Control Quality can help you envision what the plan-driven Process Groups 
model of quality management looks like. It can also help you understand quality management in general. 

This is not meant to suggest that agile approaches do not have their distinctions, but planning for and managing 


quality on projects has the same principle regardless of your projects life cycle and development approach. Following this 
discussion based on the Process Groups model is additional information that comes from agile methodologies. 


Key C) (e) 
Continuous change control Q 
feed i 
is consistent with all (E) 
approaches (uc) 


Change prompts a process Planning 
( to be reiterated through 


progressive elaboration 
or agile methods 


——> Changes that cause a 
return to Initiating are rare 


Remember, 


nemembE Executing 
it's iterative 


M&C 


FIGURE 10.1 Quality management process 


ou" About It. Many people getting ready for the exam have limited quality management experience, so they 
struggle with envisioning how quality management efforts fit into managing a project in the real world. Now that 


j you can envision the overall quality management process, walk through it as you review the following quality 
= management process flow: 


Change Change 
requests requests 
Quality 
Dept Tailor Fan 
helps processes & p 


t 
standards ai 


FIGURE 10.2 Quality management process flow 
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Understanding the Differences between Plan, Manage, and Control Quality 
One of the major challenges people have while studying this topic is understanding the differences between Plan, Manage, 
and Control Quality in the Process Groups model. Here are those three quality processes and a brief overview of each. 
e Plan Quality Management This process focuses on defining quality for the project, the product, and project 
management, and planning how it will be achieved. 


e Manage Quality This process is focused on how work is being done. Its purpose is to ensure the team is following 
organizational standards, policies, and processes as planned to produce the projects deliverables. The project manager 
also evaluates whether the quality management plan or processes need to be improved. 


e Control Quality This process includes examining the actual deliverables produced on the project to ensure they are 
correct and meet the planned level of quality, evaluating variances, finding the source of problems, and recommending 
ways to address them. 


You are not likely to encounter differences between “manage” and “control” for quality on agile-related 
questions, but understanding the difference in the Process Groups model can help you get more predictive 
questions right. 


The following chart presents a trick for understanding the three quality management processes. Study it now 
to gain an understanding of the focus of each process before reading the rest of this chapter. The trick is to 


A understand that in the “manage” process the project manager is concerned about the quality processes, 

procedures, and standards that are supposed to be used on the project, whereas in “control” the project 

manager is concerned about determining the quality of deliverables. Come back and review this chart after you read the 
rest of the chapter. 


Plan Quality Management Manage Quality Control Quality 
Process Group 


Planning Executing Monitoring and controlling 


High-Level Description of What Each Process Focuses On 


+ What is quality? + Are we following the policies, + Are the results of our work 
bat eens. metrics, procedures, and meeting the standards and 
processes as planned? required metrics? 
+ Are the procedures and e Is the variance within acceptable 
processes giving us the limits, or do we have to take 
intended results? action? 


+ Will we meet the quality 
objectives? 


More Detailed Description of What Each Process Focuses On 


+ Review project plans and + Use measurements from © Inspect and measure the quality 
artifacts to understand project Control Quality to confirm of deliverables to determine 
quality requirements. that: whether they meet requirements. 

+ Identify quality practices and - Policies and processes are ® Use the PMIS to track deviations 
internal and external standards being followed. from planned quality. 
relevant fo the product snd - Policies, metrics, and processes are © Identify the need for quality 
project (OPAs and EEFs). R : : : A 

still appropriate for the project. improvements (corrective or 


* Tailor practices and process to 
the project. 


preventive action, and defect 


- Policies and processes are effective i 
repair). 


in achieving planned quality results. 
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Plan Quality Management Manage Quality Control Quality 
+ Determine quality processes for * Use data-representation * Complete checklists and 
the project. techniques to analyze results checksheets, perform tests; 
+ Determine how you will of quality testing. evaluate results. 
measure and what work you + Determine the root cause of + Use data-representation methods 
will do to ensure you meet the problems/variances from plan. to graphically depict testing 
standards. A r results. 
+ Continuously improve to 
e Plan for process improvement. increase efficiency and * Verify deliverables. 
z ffecti ; , 
+ Perform cost of quality, pennies e Validate approved changes. 
cost-benefit, and other analyses e Create test and evaluation r 
s ; + Recommend testing process 
to ensure the appropriate levels documents for use in Control P 
z 5 improvements. 
of quality. Quality. 
i R P a * Use and update lessons learned. 
+ Determine roles and * Quality audit: Determine if 
responsibilities for achieving project activities comply with + Submit change requests. 
quality requirements. organizational and project * Update the project plan and 
r A lici i 
+ Plan for testing and inspection A DIOCesees) artifacts. 
s procedures. 
to ensure requirements, 
performance, reliability, and * Solve problems. 
ity objecti ill b 
ae 1Y UEC EVES EIDE + Produce reports. 
achieved. 


+ Integrate the quality 


requirements and constraints. 


+ Share good practices with 
others in the organization. 


management plan with other 
plans to balance the needs of e Submit change requests. 


quality with other project z 


Update the project plan and 
artifacts. 


Desired Outcomes From Successful Quality Management 


Assume 


for the exam that quality is properly planned and managed unless information in an exam question indicates 


otherwise. This means that the following outcomes should be expected as a result of quality management: 


. 


. 


Quality processes, procedures, and inspections are completed. 

The team has carefully inspected their own work to ensure it meets requirements (in manage and control quality) 

Product quality changes are made as needed before meeting with the customer to gain acceptance of deliverables (in 
validate scope). 

Changes are made to quality processes and procedures throughout the project to ensure that they are bringing the 
team and stakeholders the desired results. 

Few quality problems arise on the project since quality is carefully planned, executed, and controlled. However, in 
cases where projects are of a “research and development” nature, it is understood that trial and error is part of the 
project outcome. 

Stakeholder engagement and communications are of high quality so few or no misunderstandings with stakeholders 
should result. 

Projects routinely achieve their goals and objectives and their products deliver the value needed for the customer. This 
gives the customer the benefit for which the project was undertaken and contributes to advance the strategic objectives 
of the performing organization. 
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Plan Quality Management 


Plan Quality Management is a process to identify all relevant organizational or indus- 
try practices, standards, and requirements for the quality of the project and its prod- 
uct, and then plan on how to meet those standards and requirements. The main out- 

put of this process is a quality management plan. 
The level of quality efforts should be tailored to the needs of the project and 
quality must be balanced with the other project constraints. Standards may come 
from within the organization or from an external resource. 

That sounds easy, right? Often it is not. In many organizations, practices are not 
standardized. If this is true on your projects, take some time now to imagine 
standardized practices that would be ideal for your projects and how they might help 
you. Here is a practical example: 


Example A construction company could establish a standardized practice for 

installations on home kitchen construction projects. Imagine all the installers within that organization putting together 
their best ideas to improve the installation work on future projects. That would be a valuable effort that could improve 
quality and safety while saving time and money. Each project team would then be required to review the standard and 
tailor it to their particular project s install. 

Examples of available external standards include ISO 9000 (from the International Organization for Standardization), 
OSHA (from the Occupational Safety and Health Administration), and the United Nations Convention on Contracts for 
International Sale of Goods (CISG). 


Creating the Quality Management Plan 
As quality management is being planned, keep the following in mind: 
+ OPAs can help identify relevant standards, policies, and procedures and include lessons learned from previous projects. 


+ A project manager may create additional project-specific standards and procedures that are needed on how quality is 
defined for each piece of work. 


+ For the exam, understand that this effort should also include defining processes for how project management activities 
should be done and suggesting improvements to existing processes. 


* The customer's quality standards might be specified in a contract or need to be discovered as part of the Collect 
Requirements process. 


Quality requirements that are later used to control quality are documented, analyzed, and prioritized according to the 
requirements management plan. Examples of such standards are the: 


e Procedure for how to install a particular custom + Acceptable number of software bugs per module 
kitchen faucet * Strength of concrete 
+ Average time per installation 


Management plans and documentation that aid in quality planning include the: 


+ Stakeholder engagement plan + Stakeholder register 
+ List of the major project deliverables + Risk thresholds 

(in the requirements management plan) (in the risk management plan) 
+ Approval requirement e Scope baseline 

(in the project charter) + Requirements traceability matrix 


+ Assumption log 


The scope baseline helps the project manager maintain the proper perspective and plan quality to the appropriate 
level. The assumption log provides insight into the level of quality that is assumed to be acceptable on the project. The 
requirements traceability matrix shows the origin of requirements related to quality and will be used to confirm that quality 
requirements, including external compliance requirements, have been achieved. 
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Artifacts of Plan Quality Management 

Most quality management plans include the standard practices already discussed, along with roles and responsibilities for 
quality management. Reports and metrics that will be used are included, along with what parts of the project or deliverables 
will be measured and at what intervals. Strategies for continuous improvement of processes and procedures are 
also included. 


Planning quality will result in a number of artifacts and updates to existing documents, including: 


* Quality management plan * Project document updates 
+ Project management plan updates e Quality metrics 
Planning quality management will also result in iterations of other project artifacts. Here are some examples: 
* Scope baseline * Budget 
(Scope statement, WBS and WBS dictionary) + Risk register (to add quality-related risks) 
e Project activity list + Schedule 
+ Requirements traceability matrix + Resource assignments 


Quality Metrics 


Throughout this book there is an underlying theme that the project manager must know how the project is performing 
compared to what was planned and be able to determine when to request changes. The only way to effectively do this is to 
determine metrics in advance whenever possible and decide what range of variation is acceptable. 

Metrics to use on a project could represent the: 

+ Number of changes (to help measure the quality of the planning process) 

e Variance related to resources utilization (Were more or less resources needed than planned? How big is the variance’) 

+ Number of items that fail inspection 

+ Variance of the weight of a product produced by the project compared to the planned weight 

+ Number of bugs found in software being developed as part of the project 


Manage Quality 


The efforts for this Manage Quality process focus on making certain that the project 
work to create the deliverables is done according to the standards and processes estab- 
lished for the project in the project management plan. The project manager must also 
make sure that these quality standards are effective in meeting the needs of the proj- 
ect. 

A group outside the project team, such as a quality department, often helps with 
this work. For the exam, assume there is a quality department unless evidence in the 
question suggests otherwise. 

The Manage Quality and Control Quality processes work hand-in-hand. In 
Manage Quality, test and evaluation documents are prepared for use in Control 
Quality. In turn, this process analyzes measurements gathered in Control Quality and 


uses the quality management plan, including quality requirements, to answer the 
following questions: 
+ Are the procedures and processes being followed as planned ? 
+ Are the quality requirements, organizational policies, and processes identified in the quality management plan 
producing the intended results? 
e Can the processes and procedures be improved? 
+ How can we increase efficiency and prevent problems? 


+ Based on what we know now, is the work we planned the right quality work for this project and the right work to 
meet customer requirements? 


The process of managing quality also includes evaluating all aspects of the product design to confirm the end result 
will meet quality requirements and identifying possible improvements to the design. 257 
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Artifacts of Manage Quality 

Test and evaluation documents for use in Control Quality, such as control charts, checklists, and test plans provide a 
format with which to evaluate whether quality objectives have been met. Project documents such as a requirements 
traceability matrix may also be updated here. Quality reports interpret and document the results of both Manage and 
Control Quality activities. They can present information in different formats and are used to identify necessary changes to 
plans, policies, and processes (for Manage Quality) and to the product (for Control Quality) to ensure that quality 
requirements will be met throughout the life of a project. 


Control Qualit 


The Control Quality process addresses the quality of the product, service, or result 

of a project. Control means measure, and in controlling quality we measure whether 
the product of the project conforms to requirements. This process helps ensure cus- 

tomer acceptance, as it involves confirming and documenting the achievement of 
agreed-upon goals for each deliverable. 


What is needed to carry out Control Quality? Inputs include: 

+ Deliverables 

* Test and evaluation documents (developed in Manage Quality) 
* Work performance data 


* Quality management plan and possibly other project artifacts 


* Quality metrics (agreed-upon measures of quality developed in planning) 
+ Approved change requests (from integrated change control) 


Although a project manager and team must be involved in quality control, a quality department may complete much 
of this work in large companies. The department then informs the project manager about quality issues through change 
requests accompanied by the necessary documentation. 


It is during Control Quality that the height of doors in a manufacturing process or the number of bugs per module 
will be measured. Quality control helps answer the following questions: 


+ Are the results of the work meeting agreed-upon standards and thereby meeting requirements? 
e What are the actual variances from the standards and are they within acceptable limits? 


+ What changes in the project should be considered? 


Artifacts of Control Quality 

Control Quality artifacts include measurements, work performance information, verified deliverables, and possibly change 
requests, as well as updates to the quality management plan, issue log, test and evaluation documents, lessons learned, and 
the risk register. 


Control Quality—Specific Terminology 


To better understand questions relating to Control Quality, be familiar with the following terms: 


¢ Mutual exclusivity The exam may reference statistical terms such as “mutual exclusivity.” Two events are said to be 
mutually exclusive if they cannot both occur in a single trial. 
Example You cannot at the same time see both sides of the same coin. 
e Probability This term refers to the likelihood that something will occur. Probability is usually expressed as a decimal 
or a fraction. 


e Normal distribution A normal distribution is expressed as a chart that takes the shape of a bell curve. It is used to 
measure variations away from the “norm.” 
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e Statistical independence This concept means that the probability of one event occurring does not affect the 


probability of another event occurring. 
Example The probability of rolling a six on a die is statistically independent from the probability of getting a five 


(or even another six) on the next roll. 
e Standard deviation (or Sigma) A metric for a range of measurements is its standard deviation. This metric shows 
how far a measurement is from the mean (i.e., the average) of the measurements in the range. It signifies whether the 


range of measurements represents a stable process or output. 


If a situation posed in an exam question is looking forward in time, it is most likely a planning function. If it is 
looking back in time at processes and procedures, it is most likely part of a managing function. If it is looking 
Hiit back in time at results, like a deliverable, it is most likely part of a control function. 


Quality Management Methods 


Understanding both predictive and adaptive methods for quality management can help you get several questions right on 
the exam. The methods used to manage quality have been combined in this section to make it easier for you to understand 
them and to distinguish what tools are used in each of the three quality management processes as outlined in the Process 
Groups model. Notice that some methods can be used in more than one quality process. 


Methods for Planning Quality 


The following tools and techniques are used for quality management planning. Note that meetings can be used for 


any process. 


Interviews, Brainstorming, and Benchmarking 

You may recall learning about these techniques in the “Scope” chapter. Interviews and brainstorming can help identify 
appropriate ways to measure quality and the metrics or processes to be used. Benchmarking is utilized to review 
methodologies used by comparable projects or organizations to establish quality metrics and acceptable variance ranges, 


and to measure quality. 


Decision-making Methods 


Planning key decisions might include selecting the most critical metrics or prioritizing quality requirements. Decision- 
making tools and techniques for this process include: 

e Multicriteria decision analysis (or multicriteria weighted analysis) This method uses a matrix to list and scores 
various factors in relation to one another. It may be used in planning quality to measure the cost of quality efforts 
versus their benefits. 

e Prioritization diagram This matrix is a scatter diagram where effort is shown on the horizontal axis and the value 
of that effort is shown on the vertical axis. In quality planning the cost of quality efforts versus their benefits may be 
evaluated in this way. Note that PMI uses the term “matrix” instead of “diagram” and you may see the terms used 
interchangeably in project management literature. Technically there is a difference but you should know both terms 


since we cannot predict which will be used on the exam. 


Cost-benefit Analysis 


Using this data analysis technique, the project manager analyzes the benefits versus the costs of quality efforts to determine 
the appropriate quality level and requirements for the project. A decision-making method may be used as a tool to do this 
analysis. The exam will test your knowledge about the effects of quality efforts, or the lack thereof. Note that if you have 
poor quality, you might also have increased costs, decreased profits, low morale, low customer satisfaction, increased risk, 
and rework. These possibilities make the cost-benefit analysis and cost of quality important tools for consideration. 
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Cost of Quality (C 


Evaluating the cost of quality means making sure the project is not spending too much to achieve a particular level of 
quality. It involves balancing the costs of conformance and non-conformance to quality. There are four categories of costs 


associated with quality. They are prevention, appraisal, internal failure, and external failure. 


e Prevention These are the costs associated with preventing any quality issues from occurring. There is a cost to the 


planning and to getting systems in place to avoid having quality issues. 


e Appraisal These costs are associated with monitoring and controlling quality. Quality audits, and verification and 


validation are in this category. 


¢ Internal failure This involves finding issues before the product reaches the customer. It includes waste (performing 


unnecessary work), scrap (defective material that cannot be sold), and rework. 


¢ External failure This occurs after the product has reached the customer. The example given previously about the 
truck drivers and the touchscreen technology is an example of an external failure. External failures are the costliest and 


the impact goes beyond money to reputation. 


The following table provides examples of the costs of conformance and non-conformance to quality. 


Cost of Conformance Cost of Non-conformance 


- Quality training -Scrap 


- Studies - Inventory costs 


- Measuring quality of interim deliverables 
quality standards 


Customer satisfaction surveys (and work 


to respond to issues raised) -Warranty costs 


- Efforts to ensure everyone knows the - Lost business 


processes to use to complete their work 


Marginal Analysis 


Cost of quality is planned and then monitored and measured throughout the project life 
cycle. Marginal analysis is focused on finding the point at which the benefits or revenue to 
be received from improving quality equals the cost to achieve it. Added attention to quality 
does not produce added value. When that point is reached, the project manager stops trying 
to improve quality. 


Logical Data Models 

A data model represents the types of data an organization needs to use in a particular 
application, and the relationships between those data types. Figure 10.3 shows part of a data 
model called an entity relationship diagram (ERD). It illustrates the data associated with 
“office location” is related to data associated with “worker.” This example shows that a worker 
does not need to be assigned to an office location. This is a business rule that is verifiable 
and testable. 


Mind Mapping 


As discussed in the “Scope” chapter, a mind map is a diagram of ideas or notes to help 
generate, classify, or record information. It is used here to facilitate the gathering of quality 
requirements and illustrate their impacts on other parts of project planning. 


Matrix Representations 


A matrix is information represented in a row and column format. It visually represents the 
relationship between two or more sets of items. In planning, matrix diagrams can be used to 
list quality requirements in one column and their characteristics in others, for example, 
labels indicating levels of priority. The list could then be sorted to easily identify those that 
are most critical. An agile backlog is a good example of data represented as a matrix. 


- Rework of deliverables not meeting 


Office Location 


Location type 

Location street address 
Location city 

Location state or province 
Location country 

Location main phone number 


Ö 


houses/is assigned to 
| 


Worker 


Worker given name 
Worker family name 
Worker cell phone number 
Worker email address 
Location ID 
FIGURE 10.3 
Logical data model 
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Prioritization Matrix (Chart) hiin 

This tool can be used to numerically rank available options. It is useful for decision 

analysis about quality management planning. Figure 10.4 is a prioritization matrix Continuous Get design 100% 
indicating the project manager should do the top two choices, but probably not do Integration slant nefore Kung 
each unit test more than three times. On the exam you may find the word “matrix,” I 

“diagram," or “chart” used to refer to this tool. E 

Flowcharts Unit test Unit test more 


3 times than 3 times 


Also known as process flows or process maps, these can be used in many elements 
of project management. They show how a process or system flows from beginning Low 


a > 


to end, how the elements interrelate, and alternative paths the process can take. Low Effort High 
Flowcharts can be used to: FIGURE 10.4 
+ Define and communicate processes to be used on the project, avoiding errors. Prioritization matrix (diagram) 


+ Show dependencies in a process to determine where quality problems may 
arise in the process. 

+ Study the steps of a process that is causing a quality defect. This analysis might uncover confusion among the team or 
point out ways the process must be adjusted to make it more effective. 


N 


% 


FIGURE 10.5 A generic flowchart 


Test and Inspection Planning 


Planning quality in includes determining how the team will confirm that the required level of quality has been achieved in 
the completed project deliverables, as well as how the deliverables will be evaluated for performance and reliability. Testing 
methods, which vary depending upon the type of product, service, or result being created by the project, are used to 

control quality. The quality management plan is created to prevent quality issues. 


Methods for Managing Quality 
The following methods of Manage Quality are leveraged to analyze the processes used to create the product of the project. 
Some of the same tools are used in Control Quality to analyze product defects. 


Checklists 

A checklist (figure 10.6) can be used to confirm that the steps of a process have all been completed. It 
may also be used to analyze defects discovered in quality inspections, to look for issues within the 
process, and to assess whether a deliverable meets the acceptance criteria. 


Cause-and-Effect (Fishbone, Ishikawa, or Why-Why) Diagrams 

A team can use cause-and-effect diagrams (see figure 10.7) to confirm that policies and procedures are 
being followed and metrics are being used correctly, and that the procedures were adequate to produce 
the required level of quality in project deliverables. 


FIGURE 10.6 
Checklist 
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In the following example, the defect “system will not install” is shown on the right and then various possible causes 


are listed in an effort to find the root cause of the defect. 


Conflicting systems 


Sabotage used 


Software 


Wrong 
software 


Legacy 
systems 


Method 
of installation 


System 


will not 


Wrong install 
Hardware equipment 
installation used 
Wrong 


Software 
installation 


process 
used_ 


Lack of training 


Hardware 


FIGURE 10.7 Cause-and-effect diagram 


Scatter Diagrams 


This diagram tracks two variables to determine their relationship to the quality of the results. Figure 10.8 shows three 


examples of scatter diagrams. 


A regression line (or trend line) is calculated to show the correlation of variables, which can then be used for estimating 
and forecasting. Figure 10.8 depicts the possible resulting patterns: a proportional or positive correlation of paint quantity 
to drying time, an inverse or negative correlation of dryer fan speed to drying time, and no correlation between door 


weight and drying time. 
* Ries 0 E 
E£) Regression ine | G so Bx = ° 
z E z -° j R 
E |E E.J 4 
ou ou e+ 
€ E&E = «ee š 
s s = 4 ` 
a R, ; ga] m À 
š Jie : 
Sa Independent D 8. ae k p n 
variable m d à 
qerer eera a A STEER ye eS R Se, S 5 T 
500 600 700 800 


IT 
500 600 700 800 900 1000 11001200 1200 +400 1500 1600 sw 600 


700 800 900 1000 1100 1200 1300 1400 1500 1600 


Door paint spray quantity (mL/sqm) 


Positive correlation 


Dryer fan speed (rpm) 


Negative correlation 


Door weight (kg) 


No correlation 


FIGURE 10.8 Scatter diagram 


Histograms 


Histograms can be used to analyze the type and frequency of defects 
in order to identify where the quality improvements should be 
focused. Figure 10.9 is an example of a histogram. 


Document Analysis 


Document analysis involves reviewing the results of testing and 
other quality reports to identify ways in which the quality manage- 
ment plan and processes may not be supporting the production of 
deliverables that meet the project quality requirements. 


8 68s 8 


o 


ar 
900 1000 1100 1200 1300 1400 1500 1600 


Too lona 


Too narrow Too wide 


FIGURE 10.9 Histogram 
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Alternatives Analysis 


It is important to consider all the ways to solve an issue or problem. In Manage Quality, alternatives analysis may be used 
to evaluate which action would best impact the results of quality management processes. For example, would a new 
automated testing tool be more beneficial than redefining the testing process? 


Design of Experiments (DOE) __ 


This technique can be used for alternatives analysis and can quickly discover optimal conditions in which to produce a 


quality deliverable. Experimentation is done to determine statistically what variables will improve quality. For example, 
DOE can be used to look for ways to deliver the same level of quality for less cost. DOE is a fast and accurate technique that 
allows the project manager to systematically change the important factors in a process and see which combinations have 
an optimal impact on the project deliverables. 

Example Designers might use DOE to determine which combination of materials, structure, and construction will 
produce the highest-quality product. A caveat is that performing experiments for each variable in a process to assess its 
impacts on quality can be time-consuming and can overlook interactions among variables. 


Process Analysis 


Process analysis is part of the continuous improvement effort and focuses on identifying improvements that might be 


needed in project processes. Have you ever worked on a project where some of the activities or work packages were 
repeated? This often happens when projects have multiple installations, such as a project to install software onto hundreds 
of computers. The lessons learned on the first few installations are used to improve the process for the remaining 
installations. Though this often happens naturally, planning it into certain points in the project improves results. 


Root Cause Analysis 


Root cause analysis in Manage Quality seeks to identify the processes, procedures, and policies within the plan that may 
not work or that may need adjustment. Identifying the root cause of a quality problem helps the team to prevent it from 
recurring. Cause-and-effect diagrams (as showing in figure 10.7) help in root cause analysis. 


Failure Analysis 


This is a type of root cause analysis. It analyzes failed processes or failed components of deliverables to determine what led 
to failure. Corrective action or change requests are often outcomes of this analysis. 


Multicriteria Decision Analysis 
The project manager must facilitate quality decisions. A decision-making technique, multicriteria decision analysis is a 


complex method of numerically assessing options based on criteria such as time, cost, and quality. It can be used throughout 
a project to help the team reach agreement regarding the best way to solve a problem or improve quality. In Manage 
Quality, the team may use this technique when considering whether to adjust the quality management plan or specific 
processes or procedures. A prioritization matrix (described earlier) is a simpler decision-making technique. 


Affinity Diagrams 


We first saw this technique in the Collect Requirements process. In Manage Quality, affinity diagrams can help the project 
manager organize and group the results of root cause analysis. 

Example In Control Quality you may have determined the cause of a deliverable not meeting requirements. You can 
use this information in the Manage Quality process to determine whether a change to the standards, policies, or procedures 
in the quality management plan would address the root cause of the problem. 


Audits 

Imagine a team of auditors walking into your office one day to check up on the project. Their job is to see if you are 
complying with company standards, policies, and procedures as defined in the quality management plan, and to determine 
whether those being used are efficient and effective. This scenario represents a quality audit. Do not think of a quality audit 
as a negative event. Instead, a good quality audit will look for new lessons learned and effective practices that your project 
can contribute to the performing organization. The work of a project is not only to produce the product of the project; it 
could also contribute to the best practices within the organization, making the organization better. 
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If you do not have a team of auditors from the quality department coming to see you on your projects, do you take on 
the responsibility of looking for opportunities to identify lessons learned and best practices? Although quality audits are 
usually done by the quality department, the project manager can lead this effort if the performing organization does not 
have such a department. 


TRICKS If you see the word “audit” on the exam, the question is most likely related to Manage Quality. If you see the 
OF THE word “inspect” on the exam, the question is most likely related to Control Quality. We audit processes and we 


EMA inspect product. 
Design for X 


Design for X is another way of analyzing variables to evaluate both the effectiveness of the quality management plan and 
the team’s ability to meet objectives. The X in the name can represent an attribute of quality, such as reliability, security, or 
serviceability. If the plan is not delivering the intended results in relation to the variable being analyzed, Design for X can 
help determine what changes are needed. 


Problem-solving 

Think of how important this technique might be when encountering quality problems. Gaining a good understanding of 
the real problem is the first step towards finding an effective and long-lasting solution. Problem-solving can be used when 
considering quality improvements or to determine how best to respond to deficiencies identified in quality audits. 


The following are the steps used to analyze a quality (and any) problem: 


1. Define the real or root problem. It is often not what is 4. Pick a solution, 

presented or what appears to be the problem. 5. Implement a solution. 
2. Analyze the problem. 6. Review the solution and confirm that the solution 
3. Identify solutions. solved the problem. 


Methods for Controlling Quality 

The ultimate goal in controlling quality is to test (inspect and verify) that each deliverable meets the metrics and 
requirements as stated in the quality management plan, including the customers acceptance criteria, and that the 
deliverable is ready to move to the Validate Scope process—which should end in customer acceptance. The following 
methods were explained earlier in this chapter: 


e Checklists In Control Quality, checklists are used to determine that all required features and functions are included, 
and that they meet acceptance criteria. Checklists may be part of the test and evaluation documents created in 
Manage Quality. A quality checklist can be a list of items to inspect, a list of steps to be performed, or a picture of the 
item to be inspected, with space to note any defects found. 


e Root cause analysis This method is used to identify the cause of quality problems, including defects, to determine 
how they can be remedied so the problem does not happen again. 


e  Cause-and-effect diagrams In Manage Quality, we discussed the application of the cause- and-effect diagram to 
determine the root cause of quality issues relating to plans, processes, or procedures. In Control Quality, this tool can 
be used to lookbackward at what may have contributed to defects that have occurred as well as to analyze the impact 
of defects on the quality and acceptability of a deliverable. Look back to figure 10.7 to review this concept. 


¢ Scatter diagrams A scatter diagram can be used to control quality by comparing actual results to what was antici- 
pated, and to estimate and forecast future outcomes based on this comparison. For review, lookback to figure 10.8 and 
its accompanying description in the Manage Quality section. 
Example Imagine that our door manufacturer has a project to develop a new painted door product line. Scatter 
diagrams may be used to determine the relationship of independent variables, such as paint quantity, dryer fan speed, 
and door weight, to the dependent variable of drying time, or to correlate defects to other variables in the process. 


e Histograms and Pareto charts The results of measurements taken in Control Quality are displayed on a histogram 
to determine the problems that need the most immediate attention or that are most likely to prevent the project from 
achieving its quality requirements. 
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Compare the histograms in figure 10.10 and note that a typical histogram (on the left) presents data in no particular 
order. A Pareto Chart, as shown on the right, is a commonly used type of histogram that arranges the results from most 
frequent to least frequent to help identify which issues are resulting in the most problems. Also known as the Pareto 
Principle, the 80/20 “rule” states that 80 percent of problems are due to 20 percent of the root causes. Addressing the 
root cause of the most frequent problems makes the greatest impact on quality. 


100 


80 {| 80 7] 
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Too long Too narrow Too wide Too short Too long Too wide Too narrow Too short 
FIGURE 10.10 Comparison of a typical histogram (left) and a Pareto Chart (right) 

The following methods are specific to Control Quality. _ Defect Frequency 
Checksheets Too long will 


A checksheet is a type of checklist that can be used to keep track of data, such as 


Too narrow Il 


quality problems uncovered during inspections, as well as to document how often 


a particular defect occurs, as illustrated in figure 10.11. Too wide Willi 
Statistical Sampling Too short Il 

Let’s think about a project to create a new process for manufacturing doors. There 

would be a small allowable variation in the height and width of the doors being FIGURE 10.11 Checksheet 


made. The first efforts at creating the doors must be checked to ensure the doors 

meet requirements. But wouldn’t inspecting every door take too much time? Enough doors could be sampled to confidently 
check requirements adherence without inspecting every door. It is best to take a sample of a population if the project 
manager believes there are not many defects, or if inspecting the entire population would take too long, cost too much, or 
be too destructive. 

The sample size and frequency of measurements are determined in planning, the process is documented in managing 
quality and the sampling is done in control. Experimentation maybe needed to determine a sample size that gives the team 
a safe measure of door size accuracy. 

Sampling can also be done for project management activities. For example, you may initially check the on-time status 
for 5 out of 50 of a group’s activities. If you find issues in those 5, you can assume you'll need to check for more issues 
among the remaining 45 activities. 


Questionnaires and Surveys 
Questionnaires and surveys may be used in Control Quality to gather data on details of problems or defects, or to confirm 


that customers or end users are satisfied with deliverables that have been deployed on the project. The results can be used 
to determine whether conformance to quality has been achieved. 


Project Performance Reviews 
The project manager or quality department may conduct periodic performance reviews to formally assess how the project 


is doing in terms of meeting quality requirements. This type of review involves comparing the results of control 
measurements to metrics identified in the quality management plan. It may bring to light changes necessary to achieve 


quality requirements. 
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Inspection 


Inspections are used to verify 
generally include measurement 


s and Products TEN 


that deliverables meet the requirements. Inspections may be referred to as walk-throughs and 
of project deliverables. Checklists and control charts may be used to capture and illustrate 


the data, respectively. Inspections are also used to check that previously approved changes have been made correctly, and 
that the changes have provided the intended outcomes (validated changes). 


Control Charts 


The use of control charts and 


their parameters are established in Manage Control and are used in Control Quality to help 


determine if the results of a process are within acceptable limits. 


In this section we talk mostly about variances in product quality, but a control chart can also be used to represent and 
monitor data on project performance, such as cost and schedule variances. Outside of control charts a project manager can 
have control limits for many things. How about for a work package? Is one hour late in its delivery a problem? How about 


one day? Control limits help the 
To better understand the 
production line. To make sure 


project manager know when to act. 
need for control charts, imagine a door manufacturer undertaking a project to create a new 
the production facility will create doors that meet quality standards, it’s essential to monitor 


the processes and output so the new production line can become an ongoing business operation. Would each door be the 


same exact height? Weight? Not 


likely. Each door should be within the range of normal and acceptable limits. 


Let’s look at some of the related terms you should know for the exam. The following can be indicated on a control 
chart. As you study these terms, use figure 10.12 to envision what they mean in practice. Understanding these terms and 
how control charts are used can help you get a few more questions right on the exam. 


¢ Plotting the control 


chart During the Control Quality process, samples are taken and the data are plotted in 


software that can render a chart (see the small squares shown on the control chart in figure 10.12). The control chart 
shows whether each sample is within acceptable limits. If the data does not fall within the acceptable range, the results 
are considered to be “out of control,” which indicates a problem that needs to be fixed. 


© Upper and lower control limits Control limits are often shown as two dashed lines and are the acceptable range of 


variation of a process or 
Data points within this r: 


measurement’s results. Control limits indicate what is stable versus unstable (out of control). 
‘ange are generally thought of as “in control,” excluding the rule of seven (described later in 


this section) and are an acceptable range of variation. 


e Mean (average) The 


mean is indicated by a line in the center of the control chart. A normal distribution curve 


represents the acceptable range of variance around a mean, and it falls within the boundaries of the control limits. In 


figure 10.12, the normal 


distribution curve is on the right side of the first control chart. 


¢ Specification limits While control limits represent the performing organization’s standards for quality, specification 
limits represent the customer’s expectations—or the contractual requirements—for performance and quality on the 


project. Specification | 


imits are inputs from the customer. Therefore, they can appear either inside or outside the 


control limits. In the first chart of figure 10.12, they are the solid lines above and below the dashed lines (which 


represent the upper and 
standards for quality 


lower control limits). To meet the customer’s specification limits, the performing organization’s 
(control limits) must be stricter than those of the customer. On the exam, assume that 


specification limits are outside the upper and lower control limits. 


e Out of control The process is out of a state of statistical control under either of two circumstances: 


m/ A data point falls outside the upper or lower control limit. 


*/ There are nonrandom 


data points; these may be within the upper and lower control limits, such as the rule of 


seven (described next). 


Think of “out of control” as a lack of consistency and predictability in the process or a problem with its 


results. Also be aware 


A) 


that control limits may be called “tolerances” in agile environments and “out of dim 


control” is sometimes referred to as “out of tolerance.” Focus 


Rule of seven The rule of seven is a general rule (and you may see a general rule described as a “heuristic”). It refers 
to a group or series of data points that total seven or more on one side of the mean. The control chart on the right in 
figure 10.12 has seven nonrandom data points that fall above the mean. The rule of seven tells the project manager 


that, although none of these points are outside the control limits, they are not random, and the process is out of 


control. The project manager should investigate this type of situation and find a cause. 
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e Assignable cause/special cause variation An assignable cause or special cause variation signifies that a process is 
out of control. (See the data point sitting on the lower control limit in the left chart in figure 10.12.) If there is an 
assignable cause or special cause variation, it means a data point, or a series of data points, requires investigation to 


determine the cause of the variation. The project manager could use additional tools, such as a cause-and-effect 
diagram, to try to uncover the root cause of the variation. 


Li 
[lnr 


aoe\o\e@ 


FIGURE 10.12 Examples of control charts 


Agile Quality Management Concepts 


Many of the concepts we have discussed related to the Process Groups model may be applicable to an agile or 
hybrid project. The following sections describe tools considered to be specific to agile. These may be used 


throughout the life of a project, in both adaptive and hybrid environments. It’s important to understand these Agile 


terms and concepts for exam questions that test your knowledge of adaptive quality management practices. o 


Cost of Change 

We discuss in the “Stakeholders” chapter how important | 
it is to identify and analyze stakeholders as early as 

possible and to diligently renew this effort throughout 3i 
the project. This is because missed stakeholders with new / 


requirements later in the project increase the cost of / 
change. This philosophy applies to quality too. The Cost of Change 


| 
| 
sooner quality issues are discovered with project ($) | 


processes or a product increment being built, the easier 
and less costly it is to fix those issues and learn from them. T 


Agile and hybrid processes call for iterative and ee 


incremental development and short iterations. That (———— 

means that small increments of work can be evaluated ae Analysis & Coding Testing UAT Production 
and the team can get feedback on the evolving product as Design 

soon as possible. This allows for issues to be found early Time > 
and resolved quickly so that added costs to the project 

can be avoided. This also means less rework. The cost of FIGURE 10.13 Cost of change 


change curve in figure 10.13, shows that issues found Image copyright ©Scott W. Ambler, www.agilemodeling.com 
during a test environment (point 1) are much cheaper to 
fix than issues found during production (point 2). This is an intuitive concept but visualizing it with this figure is helpful if 


you have not encountered it before. 


Iterative and Incremental Development 

The agile and hybrid use of iterative and incremental development and short iterations, and working closely together in 
small teams means the project manager and team are willing participants in a daily feedback loop related to the work of 
building the product. This fosters quick and early awareness of quality issues when they are usually still small and minor, 
lowering the cost of change. 
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Frequent Verification and Validation 

Agile uses regular testing, short timeboxes, and reviews to meet the customer’s needs. Frequent verification and validation 
is a way to discover and address human error or the misinterpretation of customer expectations, early and often. This 
practice is built into all agile methodologies. 

Example Library software is being updated in two-week iterations. The team adds a search capability to find books 
by title. At the iteration review the team shows this new search function to the head librarian and staff. One of the staff 
suggests that the user should be able to just type the book title without putting the title in quotation marks as the demo 
showed. The team agreed to make this improvement. 


Agile Meetings (Ceremonies) Are Focused on Quality 

These types of meetings provide a way for issues to be found early in the product life cycle. One question in the daily 
standup—dre there any impediments to the project work?—can bring up potential issues and problems before there is an 
impact on quality or schedule. If a concern is brought up during a daily standup, the project manager must investigate and 
resolve that problem once the meeting is over. 


Let’s look at the four agile (or Scrum) ceremonies in terms of how they support quality. 


Iteration Planning Meeting 
The iteration (or sprint) planning meeting happens before each iteration. A lot has happened before this. The team has 


participated in the visioning of the product and the project, created a backlog of high-level requirements (as stories), 
prioritized with the help of the product owner, and have completed the high-level estimates needed to get this far. In this 
meeting further details for the upcoming iteration are worked out and details already documented are verified. 


Daily Standup Meetings | 


Daily standup meetings are designed to keep forward momentum during an iteration and to communicate so that everyone 
knows what everyone is doing and what impediments there maybe to getting the iterations work done. No troubleshooting 
is done and the project manager investigates identified impediments after the meeting. 


Meeting rules are meant to keep the meeting short and focused, and for participants to answer these three questions: 
1. What have you done since the last meeting? 
2. What are you working on today? 


3. Are there any issues or impediments to your progress? 


Retrospectives and Meetings _ 
While a retrospective meeting in a plan-driven environment is typically held at the end of the project, in an agile or hybrid 


environment retrospectives most often take place at the end of each short, time-boxed iteration. The retrospective is an 
opportunity for the members of the development team to inspect and adapt their methods and teamwork. Can you see 
how this would be valuable to improve quality and identify issues as the product is being developed? 


During the retrospective, the following questions are discussed: 
1. What is going well? 
2. What areas could use improvement? 


3. What should we be doing differently? 


Work in Progress (WIP) and Cycle Time 
Work in progress (WIP) is the number of unfinished pieces of work going on at one time. Using Kanban boards are a 
common method of limiting work in progress. Excessive WIP is associated with several problems: 


+ It represents money that has been invested but isn’t producing any return yet. 
* It hides bottlenecks and masks efficiency issues. 


* It carries the risk of potential rework if quality issues are discovered. 


Agile and hybrid approaches place emphasis on limiting WIP to address these risks. Here, we’ll look at some concepts 
related to WIP and how project managers limit WIP. 
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First, we'll look at lead time and cycle time. Figure 10.14 is a Kanban board that shows the difference between lead 
time and cycle time. 


e Lead time This measures the length of time of an entire process. For example, from design to shipping, or from 


requirements gathering through development to deployment. 


Cycle time This measures the length of time to go through part of the process. For example, from assembly to 
painting, or from coding to testing. 


Lead Time 
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Cycle Time for Development and Testing 
FIGURE 10.14 Lead time and cycle time illustrated on a Kanban board 


Cycle time can be calculated by using a formula that involves WIP and throughput. Throughput is the average time it 
takes to complete the work (for example, the entire work of one iteration). Notice that throughput represents a global 
average—in this example, for an iteration—not just an average for a particular cycle time. 


WIP 
€ycle time = ------------------------- 
Throughput 


Example Let’s say the team has 18 points of WIP and is working at a velocity of 27 points per iteration, which is the 
throughput. So, 18 divided by 27 equals a cycle time 6.6 points. 

Cycle Time = 18/27 = 6.6 

(or 6.6 days for a 10-day iteration) 

In other words, each of the cycles in question are on average 6.6 points worth of work. 


Long cycle times mean there may be too much WIP, which increases risk and quality issues. Agile and hybrid 


approaches avoid this by breaking the work down into small batches and focusing on finishing these and getting customer 
acceptance as soon as possible. 


Defects 
Agile and hybrid projects also track the defect cycle time. This is the amount of time between when the defect was 
introduced to the time it was fixed. By doing so, the project team can keep the cost of change to a minimum. Some project 


teams actively track their average defect cycle time and set goals for the quick resolution of defects. This can minimize the 
cost of fixing defects. 


Keep Project Environments Open and Safe for People 
A student in an RMC class confided in the instructor that they had discovered a defect on an iteration for webpage 
development and were afraid to tell their project manager. The project manager, they said, would often call people out in 


daily standups and embarrass them. The student was hoping that the defect would be caught later when it was hard to trace 
back the work to them. 
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As we’ve said before, defects found later increase the level of risk to the project. Think back to that cost of change 
curve. It is less costly for the defect to be fixed as soon as it is known rather than later when the finished product is too 
complex to troubleshoot. 

It is important for the project manager to create an environment where people feel comfortable to speak up and note 
issues as soon as possible. Project managers should take every opportunity to let team members know they can bring up 
issues and ask for help. By identifying problems early, the project can stay on track and save time and money. 


Quality Management Outcomes: A Summary 


Good quality management creates the opportunity to deliver a product with few or no defects, and that is fit for the purpose 
as defined by documented definitions of done and acceptance criteria. Product delivery and project closure should be in 
line with the approved schedule and budget, and at the agreed levels of quality. The product should meet the organizations 
and customer s business goals and objectives for which the project was chartered. 

Quality management, in concert with stakeholder engagement efforts, should result in customer satisfaction, and 
successful and improved procurements (through good supply chain integration practices). Through teamwork and servant 
leadership the team and organization should benefit from continually improved processes, decision-making capabilities, 
and productivity. Project team satisfaction and motivation should be maintained or enhanced. 


Understanding the Tools and Techniques Used in Quality Management 


As you have read through this chapter, have you found yourself asking questions like, “Now, when are all these tools and 
techniques used?” or “What are the differences between the three parts of the quality management process again?” People 
tend to struggle with these concepts. The following exercise will help. 


10.1 Exercise 

Take time to research in this book the different methods that are created or used in each of the quality management 
processes. Then, in your Exercise Notebook, identify whether the following tools are used in planning, managing, 
and/or controlling quality. Remember that some tools and techniques are used in more than one quality 
management process. Think about the ways they are used for different purposes in each process. 


1. Affinity diagrams 16. Interviews 

2. Alternatives analysis 17. Logical data model 

3. Benchmarking 18. Matrix diagrams 

4. Brainstorming 19. Meetings 

5. Cause-and-effect diagrams 20. Mind mapping 

6. Checklists 21. Multicriteria decision analysis 
7. Checksheets 22. Performance reviews 

8. Control charts 23. Problem-solving 

9. Cost of quality 24. Process analysis 
10. Cost-benefit analysis 25. Questionnaires and surveys 
11. Design for X 26. Root cause analysis 
12. Document analysis 27. Scatter diagrams 
13. Flowcharts 28. Statistical sampling 
14. Histograms 29. Test and inspection planning 
15. Inspection 30. Testing/product evaluations 
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Answer 
Tool 
1. Affinity diagrams 
2. Alternatives analysis 
3. Benchmarking 
4. Brainstorming 
a Cause-and-effect diagrams 
6. Checklists 
Ws Checksheets 
8. Control charts 
9. Cost of quality 
10. Cost-benefit analysis 
11. Design for X 
12; Document analysis 
13, Flowcharts 
14. Histograms 
15. Inspection 
16. Interviews 
T Logical data model 
18. Matrix diagrams 
19; Meetings 
20. Mind mapping 
21. Multicriteria decision analysis 
22, Performance reviews 
23. Problem-solving 
24. Process analysis 
25. Questionnaires and surveys 
26. Root cause analysis 
27. Scatter diagrams 
28. Statistical sampling 
29. Test and inspection planning 
30. Testing/product evaluations 
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Used in Plan Quality 
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Putting It All Together 


Do you think you understand quality management now? The following exercise will help you review the information you 
have learned. 


10.2 Exercise 
Using our library example, match the work described with the Quality Management process (processes may be 
used more than once). 


1. Plan Quality Management 
2. Manage Quality 
3. Control Quality 


Work 


A. Ask the city council for their expectations about the quality levels of the 
library furniture. 


Coordinate the date and time for the planned city inspection of the foundation. 
Discuss the one inspection failure with the construction foreman. 
Ask IT director to report the number of defects found during software testing. 


Create a change request to the design after a problem is discovered. 


m= moO p 


When choosing a moving company to pack and move the existing books, ask for 
insurance claims on their last three moves. 


G. Hire a cybersecurity audit for the patron login functionality. 


Answer 
A. 1 


a7 mon f 
wo NYO Ww NH 
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Introduction 


Have you ever sent a message you were certain was very clear but then you got a lot of questions about 
it after it was received, or you learned later that it was misunderstood? What about times when you’ve 
left a voicemail or an email for a particular person only to find out later it would have been received 
much more quickly if you had texted the person instead? What are your communication preferences? 
Maybe you’ve recently received a voicemail in the office when you are now used to checking only your 
mobile phone. 

When you think about it, communication is involved in almost everything you do as a project 
manager. There are so many technologies and methods to choose from, and so many variations in ways 
to interpret a given message that issues with communications are inevitable. From sheer volume alone 
it is no surprise that project managers identify communication-related issues as the number-one 
problem experienced most frequently on projects. 


Communications ment Overview 


The project manager must plan, manage, and control communications carefully so the best technolo- 
gies and methods are chosen for a given audience. Then, the project manager has to craft each message 
carefully for clarity and the optimal amount and types of detail. Here are just a few examples of factors 
affecting project communications: 


+ Projects often involve virtual teams, requiring complex communication tactics and strategies. 
+ The rapid rate of change on projects necessitates continually revisiting communication tactics 
and strategies, and past communications. 


* Stakeholder communication preferences lead to a need to choose communication tactics and 
strategies carefully. 


Planning and managing communications may also include: 

+ Assessing stakeholder communication needs (part of stakeholder identification and analysis) 

* Determining what methods will be best for the project 

+ Understanding what communication channels are available 

+ Deciding on the frequency and level of detail of particular types of project communications 

+ Ensuring appropriate methods for effective feedback loops are provided and understood 

+ Considering the richness of available communication channels in choosing communication 
technologies and methods 

+ Revisiting decisions regarding the selected communication tactics and strategies to ensure they 
remain effective throughout the project 


On the exam, communications questions are frequently combined with other topics. Stakeholder 
engagement is an obvious content area that feeds into decisions needed to create well-planned 
communication plans and to carry them out. All other knowledge areas are affected as well. 

Examples Tools related to scope management—WBS, story backlog, or release—are also used 
to communicate with stakeholders. 
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The Examination Content Outline and Process Groups Model 
Hie following table illustrates that the ECO combines communications management activities into a single task called 
Manage Communications, while the Process Groups model has communications management activities broken into three 
main processes mapped to the planning, executing, and monitoring and controlling process groups. 


Domain II Communications Management Domain 2.1 
Stakeholder 
Task 2 Plan Communications Management — Planning Domain 2.2 
Manage communications T i 
Manage Communications — Executing pam 
Monitor Communications — Monitoring Domain ae 
& Controlling Planning 
Domain 2.5 


Project work 


Domain 2.8 
Uncertainty 


Think about it. In addition to “Manage communications” from the ECO, many other ECO tasks are connected 
: to communications management. Review the below tasks in the ECO and think about how they are all holistically 


a involved in managing communications, and how they in turn depend on communications management. The 


following examples are not all-inclusive. 


We mapped the Process domain tasks here more directly to project integration management to give you an opportunity 
to review these again. As a project manager, integration of everything happening on a project is one of your 


primary responsibilities. 


Examples 


People (Domain |) 


All People domain tasks are critical to 
effective project communications. The 
reverse is true as well: Effective project 
communications are integral to success 
in all People domain tasks. 


Process (Domain II) 

+ Execute project with urgency to deliver business value (task 1) 
+ Engage stakeholders (task 4) 

+ Integrate project planning activities (task 9) 

+ Establish project governance structure (task 14) 
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Now take some time to review the communications management process according to the Process Groups model. 
The Process Groups model perspective gives you an overview of the general process, which can guide you through the rest 


of the chapter. 
x) 
(J 
i : 


Key 


Continuous change control is 
7 EEG 
“Consistent with all approaches 


Change prompts a process to be Planning 
( ; reiterated through progressive 


elaboration or agile methods 


Remember, 
it's iterative 


= > Changes that cause a return to 
Initiating are rare 


FIGURE 11.1 Communications management process 


Before delving into the more technical project management aspects of communication management, you may want 
to skim through the Communication Skills section of the “Leadership Skills” chapter. Keep this and all the People domain 
tasks in mind as you study this chapter. 


Desired Outcomes from Successful Communication Management 

Assume for the exam that project communications are properly planned and managed unless information in an exam 
question indicates otherwise. This means that the following outcomes should be expected as a result of 
communication management: 

e Communications are planned and executed so that the right information gets to the appropriate stakeholders using 
the appropriate technologies, is clear and understandable, and arrives to stakeholders at the right times and in the 
appropriate formats. 

e The project manager solicits feedback from receivers of communications to ensure a common understanding of all 
information conveyed as well as the need, if any, for follow-up actions. 

+ Communication strategies and tactics are measured and analyzed on a regular basis and appropriate changes are made 
as situations or communications needs on the project changes. 

+ The project communication management strategies and tactics contribute to stakeholder satisfaction because 
stakeholders understand what communications to expect and when. They also are confident that they will receive 
communications appropriate to their needs on the project. 
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Communications Planning 


Planning is about considering the projects overall communications approach for 
the project, and about how the project manager will sort out the fine detail. The plan 
should identify what systems and processes are already in place to support commu- 
nications, as well as what processes and documents must be created. This effort in- 
cludes planning what information will be communicated to whom, when, using 
what methods, and how frequently. The plan will guide the project manager and the 
team in managing and monitoring communications to ensure information is getting 

to where it is needed, is clear and understandable, and allows stakeholders to act as 
necessary. Finally, it should have the flexibility to change as the project progresses 
and the information and stakeholders’ needs change. 


To plan communications, the project manager will refer to the project charter 
and other artifacts like requirements documentation, the stakeholder register, and 
the stakeholder engagement and resource management plans. The communications 


plan should explain how project communications will support related areas. 


On your projects, do you take the time to ask stakeholders about their communications requirements? 
Communications requirements need to be analyzed to determine how they can be met and to make sure that meeting 
them will add value to the project and will be worth the effort and cost involved. 


Project size, life cycle, and development approach are all factors for consideration in communications planning. The 
project manager needs to be equally comfortable with planning communications for projects large and small, using 
predictive, adaptive, or hybrid approaches. A large project may have a team of over 100 people in different countries, 
speaking different languages, with diverse approaches to communication, possibly influenced by culture. A small project 
may be accomplished entirely from one location or may have simpler communication needs. In other words, 
communications efforts must be tailored to the project. 


In hybrid environments, for example, project leaders communicate some project information through 
both predictive and agile methods. Leaders of agile teams in hybrid environments must often update weekly 
status reports, Gantt charts, and earned value reports in addition to tracking agile metrics like velocity and Lad 
burnup and burndown information. 


Think About It. Communication management is important on the exam. Think about everything you have 
p read so far in this chapter as you look at the following list. Do you do the following? 


D + Use multiple methods of communicating. + Plan how you will confirm communication is 
+ Ask people what information they need received and understood. 
and when. e Cater to the need for communication to go in 
* Tailor communication practices to project multiple directions, at all levels, internal and 
size, complexity, life cycle, and approach. external to the organization. 
* Plan communications for each stakeholder or + Analyze how location, culture, security, 
group based on individual needs and interests. privacy, and language impact communications. 


+ Have a system for storing, maintaining, and 
retrieving project information. 
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ELEVEN Communications 


Test yourself! Write down in your Exercise Notebook what information needs to be communicated on a project. 


Answer 


Some possible answers are: 


© Project charter 

® Stakeholder contact information 
è Types of emails to be sent to each 
stakeholder or group 


© Artifacts (plans, release maps, user stories, 
backlogs, WBS, network diagram) 


® Dependencies 

© Impacts to and from other projects 
© When resources will be needed 

® Team norms 

® Working agreements 

è Definition of done 

© Bum charts 

© Information radiators 

® Meeting schedule 


® Work assignments 


Communications Requirements 
Understanding and fulfilling communications 


requirements 


Status 

Uncertainties (esp. new risks uncovered) 
Problems 

Successes 

Project and product scope changes 


Information about when management 
reviews will be done 


Updates when plans are changed 
Change request results 

Upcoming work (e.g., scheduled WBS 
components or iteration backlogs) 
Delays 

Date of next milestone completion 
Performance reports 

Retrospective results; lessons learned 
Issue logs 


Configuration management issues 


helps the project manager maintain stakeholder engagement 


by ensuring that communication needs are met. More information about requirements analysis is in the “Scope” chapter. 


Use the following information to determine and analyze communication requirements: 


* Stakeholder register 
+ Stakeholder personas 


+ Stakeholder engagement plan 


Artifacts of Communications Planning 


+ Locations of stakeholders 


+ Number of communication channels 


As a result of planning communications, the project manager should have a documented description of the communications 
needs of stakeholders and a strategy to meet them. Plan components may include: 


+ What communications to prepare and disseminate + Who has responsibility for sending and receiving 


among stakeholders which communications 


* How information should be named and stored . 


+ Who has access to what communications 


* Who has the ability to edit what 


Tailored approaches to language and culture 
* Tailored approaches to level of detail needed 


+ Information on how communication effectiveness 
will be evaluated 
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Because communications are complex, a communications management plan should be in writing for most projects. 
Figure 11.2 shows some of the considerations for what you might include in a communications plan. 


What Needs to Be Best Method for Responsibility When and 
Communicated Why Between Whom Communicating for Sending How Often 


FIGURE 11.2 Sample portion of a communications management plan 


Managing Effective Communications 


During planning, the communications needs of stakeholders are determined and 
documented. Throughout the project, the project manager and team satisfy these 
needs through meetings and other in-person communication, as well as through 
other communications such as reports, graphics, information radiators, and emails. 


Almost nothing on the project gets done without communicating, so it’s 
important that information is flowing back and forth on the project in accordance 
with the planned strategy. Communicating effectively is about facilitation and 
practicing flexible approaches in dynamic environments. It also includes providing 
opportunities for stakeholders to request additional information and clarification. 


su=d(@,.¢ While reports and other formal written communications are important 
©] S| aspects of the project’s historical records, they should not require a 
great deal of a project leader’s or team’s time. 


Often communications are tailored to the audience. In hybrid environments, 
a project leader might discuss “points,” "Planning Poker",” “velocity,” and “blockers” with the team, and then 
use more traditional terminology like “completed work,” “progress," “estimates,” and “threats” with a more Agile 
plan-driven-focused steering committee. i 

Example With the team, a project leader might say, “I have a stakeholder meeting. I’ll be showing our burndown 
rates by iteration.” With the steering committee, they might say, “These are our average feature completion rates as measured 
every two weeks.” 

It is vital to use the interactive communication model (as shown in figure 5.3 in the “Leadership Skills” chapter) and 
appropriate methods and technology planned for the project so everyone knows what to do with the information they 
need to convey. The communications management plan, project documents, work performance reports, and everyday 
interactions will give the project manager the data and information about what needs to be communicated. Whether it's 
information from recent risk reviews, forecasts on project performance, or details about changes that have gone through a 
formal integrated change control process, the project leader and team need to follow the communications management plan. 

Tailoring is also often needed in response to stakeholder feedback, the culture of the organization (which is always 
evolving), and other factors. 


Methods for Communication 

Communication methods were discussed in the “Leadership Skills” chapter. A large range of communication and 
interpersonal and team skills also helps the project manager manage communication choices. These may include but are 
not limited to active listening, conflict management, cultural awareness, meetings management, networking, and political 
awareness. Developing and delivering presentations and reports are also important competencies, as is tailoring 
communications to the audience at a given time on the project. 
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Meeting Management 


Meetings are often key elements of the effort to manage communications. We have already said that the project manager 


and the team need to decide during planning how information will be shared on the project. Meetings provide a way to 


communicate with the team and stakeholders. Having a strategy for meetings is essential to making time spent in meetings 


efficient and effective. This includes sticking to the planned strategy for how meetings will be conducted, who needs to 


attend, and when they are most appropriate. 


Effective meetings may seem easy to plan but they are not easy to conduct consistently. Consider the following 


meeting rules: 
e Meet regularly as appropriate + Remind attendees of their meeting responsibilities 
+ Bring the right people together as appropriate 


+ Schedule recurring meetings in advance 


+ Have a purpose for each meeting (not just the facilitator) 


e Cancel an instance of a recurring meeting if it ; 
A that result from meetings 
is unnecessary 


+ Set time limits and keep to them + Document and publish meeting minutes, 
as appropriate 
+ Have an agenda and stick to it EESE 


+ Make all participants responsible to enforce rules 


+ Assign deliverables and time limits for assignments 


+ Adhere to inherent rules for particular types of 


* Distribute the agenda beforehand i ji 
meetings (e.g., daily standups) 
+ Chair and lead meetings with a set of rules 


Hybrid environments may present short-term challenges in relation to meetings. An agile team’s “less 
formal” practices may make traditional stakeholders uncomfortable at first. A way to resolve this is to have 
stakeholders observe the agile team’s daily standup meeting. This is a great way to learn about team dynamics 
and current work activities. And since these meetings are normally held in the team’s work area, there are 
likely to be information radiators on the walls to help inform stakeholders. 


TRICK People unfamiliar with agile worry that reporting is too informal for traditional stakeholders. The fact is, in 


Agile 
Focus 


OF TH agile the same things are being tracked even though effort is counted in story points rather than hours or days. 


TRAD On a weekly basis the team may be concerned only with the current iterations story points, but over time 


this data can easily be turned into an earned value measurement (EVM) report (see figure 11.3). 


500 
USD 75,000 

D 

a 400 Eamed Value (EV) Cost Variance (CV) 

8 Enhanced member USD 60,000 
2 benefits 
g 300 Member billing USD 45,000 
[=] 
iQ. 

= 

2 200 y Basic member USD 30,000 
ma \ benefits 
wo Scheduled Variance (SV) Member access USD.15,9000 


Configuration 


Jan Feb March April May June July Aug 


Planned value (Pv) ===» Planned cost/spend sm Scope built = Actual cost/spending 


_ Completed features Eamed value 


~ Planned features ~ Actual cost 


FIGURE 11.3 Agile earned value measurement (EVM) 
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Standup Meetings Standup meetings may be used to learn about progress, opportunities, threats, and issues. They may 
also be used to share information between team members and other stakeholders. 


Iteration Reviews These are meetings with the specific purpose of the team giving a demo to the customer of newly 
developed scope, and either getting acceptance and sign-off on that scope increment or gathering the feedback needed to 
do so at a later time. 


Retrospective Findings These may also be included on an information radiator. In hybrid environments retrospective 
findings can serve as ongoing lessons learned. Then, the requisite lessons learned reports at the end of a project are 
constructed from them, contributing to organizational process assets. 


Project Reporting 

Project reporting involves communicating to stakeholders about how the project is going and how it is projected to go in 
the future. Much of that information comes from work performance reports. It also involves asking for feedback from 
stakeholders to ensure they have received the information they need and have understood it, and to determine whether 
they need more. Outside of daily interactions, meetings, and information radiators, this communication may take the form 
of written reports, presentations, and intranet updates as outlined in the communications management plan. 


Make sure you remember the following about reports. They should: 
+ Be designed to fit the needs of the project. 
* Provide information and at the level of detail required by stakeholders. 


+ Include measurements against the performance measurement baseline set for the project, phase, or iteration (for 
scope, schedule, cost, and quality). 


+ Use the most appropriate communication method when sending information. 


* Be truthful. This should go without saying but because it is not always the case, there may be exam questions about 
reports connected to professional and social responsibility. 


+ Help team members know when to recommend and implement corrective actions. 


In addition, feedback from stakeholders (who receive reports as part of this process) should be analyzed to allow for 
tailoring of future communications to continue to or better meet stakeholder needs. A project manager might issue the 
following types of reports: 


* Status report Describes project performance compared to the performance measurement baseline. 
* Progress report Describes what has been accomplished. 

° Trend report Examines results over time for performance improvement or decline. 

* Forecasting report Predicts future project status and performance. 

* Variance report Compares actual results to performance measurement baselines. 


° Earned value report Integrates scope, cost, and schedule measurements to assess project performance relative to 
baselines and variances. 


+ Progress metrics Reports such as Cumulative Flow Diagrams and burnup charts are used to assess performance. 
+ Retrospective findings Used to inspect, adapt, and improve project and team performance. 


e Lessons learned Summaries of lessons learned that may be used immediately on the project or used for 
future projects. 


Knowledge Sharing 


Any of the reports listed previously can be used on projects to share information. Discussing this information and what it 
means in order to help each other improve individual and project performance is knowledge sharing. This is a key 
component of successful project management communications. Information is a basic element of any project so it must be 
distributed and shared. Have you managed a project for which the team reported they didn’t have all the necessary 
information, or they didn’t know how to use the information they had received? 
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Example Let’s say a team member was unable to complete a task or activity because of missing information or 
knowledge. This was due to a team member’s vacation that was not communicated to the whole team. How would that 
impact the project? What could have been done differently to avoid such an issue? If the project team properly shared 
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information and knowledge, that team member would not have trouble completing their work. 


Agile projects embrace knowledge sharing using a variety of tools: 


Similarly, agile emphasizes collaborative planning, estimating, and retrospectives. This allows the project team to 


Daily standup meetings 
Kanban boards 
Personas 


Release and iteration planning 


collectively gather and share project knowledge. 


Information Radiators 
A Kanban board (see figure 11.4) is a 


method 
(WIP), 


showing WIP. A Kanban board is a great 


way to 


and to illustrate WIP. 


In: 


in front of these task boards. Seeing the 
finished work piling up to the right of the 


board 
stakeho 


The types of information shown via information radiators may include large charts, graphs, data summaries—or even 


a computer screen showing continuous integration results on software projects. Displayed in high-traffic areas, they allow 


anyone 
In: 


for limiting work in progress 
and it is an information radiator 


track workflow, project progress, 


ormal meetings often take place 


also provides inspiration for 
ders and team members alike. 


to see the project progress at any time. 


ormation displayed using information radiators may include: 
Features delivered to date and features remaining 

to deliver 

Features for the current iteration 

List of issues, threats and opportunities (risks) 


Bum charts 


Artifacts of Manage Communications 


Reports, information radiators, and the individual communications are the artifacts of project communications, usually 
kept in writing in the PMIS. Handmade information radiators are often photographed before they are changed in a 
significant way. For example, a drawing on a whiteboard may be recorded this way before it is erased and redrawn using new 


Story Ready Task Ready Task In Process Task Done 


* Product demos 


+ Information radiators Agile 
Focus 


+ Wireframes (a type of low 
fidelity prototyping) 


+ Retrospectives 


Story Done 


FIGURE 11.4 Kanban board 


+ Who is working on what 
+ Velocity metrics 
+ Defect metrics 


+ Story maps 


options. Here are some of the more formal artifacts that are updated on a regular basis: 


Project communications 
Communications management plan 
Stakeholder management plan updates 
Project document updates 

V Issue log 

V Lessons learned 

V Risk register 

y Stakeholder register 


Organizational process assets 
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Monitor Communication Effectiveness 


Of course, as the project manager is managing (or carrying out) effective communi- 
cation on the project, they are at the same time monitoring it to ensure its continued 
efficacy. The project leader should assess and ensure that information is flowing as 
planned—in the right way, to the right people, and at the right time. This effectively 
keeps stakeholders and the team informed and maintains the desired levels of stake- 
holder engagement. The previous section listed types of data and reports with the 
assumption you know what and how to collect data and transform it into informa- 
tion. 

If you’re not familiar with data collection and evaluation techniques, think 
about how you would use them and how they may differ on different types of 
projects. This process involves: 


e Observing to determine whether the communications management plan is 
being followed 


* Confirming communications and feedback are understood 
+ Ensuring that communications are meeting the needs of the stakeholders 
+ Identifying where communication is breaking down (if needed) 


+ Adjusting as necessary to meet stakeholder and team needs 


How can the project manager tell if communication is breaking down? In addition to the established metrics, they 
rely on interpersonal and leadership skills. Some issues may be clearer than others. Project stakeholders may let the project 
manager know, for example, if they’re not getting the reports or information they’re meant to receive. Or the project 
manager will be informed if the project team isn’t following up on action items established through earlier communications. 
Also, project team members should report any communication problems they experience and help to identify ways 
communications can be improved on the project. These are the reasons it’s important to encourage all stakeholders to let 
the project manager know whether the project communications are meeting their needs. Do you do this on your projects? 


Putting It All Together 


Communications is more than technology; it also involves the interpersonal and team skills every project manager needs 
to be a successful leader. Make sure you understand the various communication methods and what is in a communications 
management plan. 


Important concepts can be found on the Quicktest at the beginning of the chapter. Use it to find any gaps in your 
knowledge. Review the chapter again to fill those gaps, then complete the following exercise. 


11.2 Exercise 


Give examples of the communication challenges the project manager may have with each of the stakeholder or 
stakeholder groups from our library case study. Suggest ideas for good communication plans. 


Stakeholder or What will be the communication How will the PM best communicate with this 
group challenges with this stakeholder? stakeholder? 

Mayor 

City Council 

Patrons 

Librarian 


Construction team 
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Answer 


Here are some sample answers. You may have come up with some other ideas. 


Stakeholder or What will be the communication How will the PM best communicate with this 

group challenges with this stakeholder? stakeholder? 

Mayor Mayor is busy and has many other Since the mayor is probably busy, the project 
issues to manage. manager will want to get to know the mayor’s 


assistant and ask for the best ways to communicate. 


City Council Some council members are always up The project manager should communicate the 
for re-election and may be using the same messages to all council members. 
library as an issue. 


Patrons Large group, little direct contact. Public notices in newspapers and magazines. 
Surveys. 
Librarian The librarian may be comfortable with Keep the librarian engaged in all decisions. 


the current library and resist change. 


Construction team Managed by another company so the Work with the construction company management 
project manager does not have direct to communicate information to the workers. 
authority 


285 


2841 


£ Risks and Issues 


Introduction 


The impact of risk management is integral to a project manager’s daily work and the exam will test your 
knowledge of risk management at a sophisticated level. For example, you may be given a situation and, 
based on the information provided, need to determine which risk management process is being per- 
formed or what should be done next. 

Before we look at the risk management process in detail, let’s start with a story. An RMC student 
was a project manager on a hardware and software installation project in an area where hurricanes are 
a relatively frequent occurrence. Then a hurricane struck. Not long after the hurricane was over, the 
project manager told people what a great job his team had done and how quickly they had recovered 
from the disaster. 


Think About It. Would you have been proud of yourself if you were the project manager? As 
-you answer, consider the following information: 


aa + The activity the team was working on required three days to complete. 
+ The project manager had warning that the hurricane was coming. 
* They had to recover from the disaster. 


Instead of being excited about how quickly his team was able to recover from the hurricane, the 
project manager—and the sponsor—should have questioned the wisdom of scheduling the 
implementation at a time when there was a strong probability of a hurricane. Or, if the scheduling had 
already been completed, they should have questioned the wisdom of keeping to that schedule. This is 
the value of risk management. When a hurricane was forecast the team could have responded according 
to a plan, such as moving the implementation to another weekend to avoid the danger, damage, and 
rework that was likely to result. 

A project manager’s work should focus on preventing problems rather than on dealing with them. 
Think about your own projects. How would it feel if you could say, “No problem; we anticipated this, 
and we have a plan in place that will resolve it whenever a problem occurs”? How much time and 
money would you save that would have otherwise been spent addressing the problem? How much less 
stress would you have in your life? 

Projects inherently include uncertainty, volatility, complexity, and ambiguity (discussed in the 
Uncertainty Domain in the PMBOKS Guide). Project risk management helps prevent many threats (or 
negative risks) and make others less likely or less impactful. And it helps to increase the probability 
and/or impact of opportunities (positive risks). When the project manager eliminates threats and 
increases opportunities, schedule and cost estimates can be decreased. With that in mind, we’ll look at 
some of the basic risk management concepts. 


Definitions Related to Risk Management 
Here is some basic vocabulary that will be used in this chapter. 


Project Risk 


A probable event that, if it occurs, will negatively or positively affect one or more project constraints. 
A risk can affect the project team’s ability deliver the value for which the project was chartered and 
meet the agreed-upon budget, schedule, and quality requirements. 
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Project Risk Management 
This is the process of identifying, evaluating, and planning responses to uncertain events that might occur during the 


course of a project. The project manager identifies risks and begins to manage them in initiating and planning. While the 
project is underway the project manager and the team frequently look at what uncertain events have happened or may 
soon happen, and reassess the planned risk strategy. 


Watch List 
This is a list of risks that currently do not warrant planned risks responses, but it is understood that any of these risks 
could become more probable and need a planned response. 


Risk Owner 
An individual who watches out for the occurrence of an assigned risk and leads the implementation of 
preplanned responses. 


Threats and Opportunities 


A risk event can have positive or negative impacts on the project if it happens. We often focus on threats, which are things 


that can go wrong. But there can also be opportunities on projects—positive impacts that may allow the project manager 
and team to deliver even more value to the organization and customer than planned. 
Opportunities can include such things as: 
+ Ifwecan combine orders for the ZYX equipment, buy more than 20 items at once, we could decrease the cost by 
20 percent. 
+ Ifwe can train the team to improve efficiency, then work package number 3.4 (and possibly others) could be completed 
two days faster than expected. 
+ If we can obtain a more experienced resource with a higher level of productivity, then the critical path activity 4.7.2 
could be done 10 percent faster. 


Projects have the potential for many opportunities, and the vast majority of identified threats can be mitigated or 
eliminated by changing how the work is planned and performed. There are strategies that may reduce threats and even 
create opportunities; for example, careful resource optimization, using the most experienced people possible and providing 
training as needed. 


Even though threats are what we often think about when we hear the word “risk,” for the exam remember there 
is as much likelihood that you'll see questions related to opportunities. The iterative nature of project 
management methods also requires a continuous attention to updating the risk management plan. Risk 


identification and planning is ongoing throughout a project. 


> Think About It. The concept of risk is so closely related to value that we can think of negative project risks 
(threats) as “anti-value”—factors that have the potential to erode, remove, or reduce value if they occur. Think of 
the value you create with your project as money you bring into the household budget. You plan to accrue value 
in the budget with work effort (resulting in paychecks). Threats that actually occur like an unexpected expense 
remove money from the budget so it now has less value. An unexpected bonus, however, can potentially increase 
the value of the budget. To create the most value, you maximize monetary flow into the budget (opportunities) 
and minimize unexpected outflow (threats). 


Risk Factors 


When assessing risk, the project manager needs to determine the: 
* Probability that a risk event will occur (how likely) 
+ Range of possible outcomes (impact or amount at stake) 
+ Expected timing for it to occur in the project life cycle (when) 


+ Anticipated frequency of risk events from that source (how often) 
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Risk Appetites and Thresholds 
These terms refer to the level of risk an individual or group is willing to accept. 
¢ Risk appetite Also referred to as risk tolerance, this is a general description of the level of risk acceptable to an 
individual or an organization. 
Example A sponsor may be willing to accept little risk to the schedule on a project. This may (and should) make 
the sponsor more flexible with cost since adding resources can compress the schedule (this is known as “‘crashing”). 
¢ Risk threshold This refers to the specific point at which risk becomes unacceptable. 
Example The sponsor will not accept the risk of a schedule delay of 15 days or longer. 
e Risk averse This term describes an individual or organization with a very low appetite for the negative impact 
of threats. 


Risk appetites and thresholds vary and can include any project constraint (scope, schedule, cost, etc.), as well as risks 
to reputation, customer satisfaction, and other intangibles depending on the individual or organization. 

Example An organization may have more tolerance for cost-related risks than for risks that affect customer satisfaction 
or their reputation in the marketplace. 


When answering exam questions related to risk response strategies, look for information about individual and 
organizational risk appetites and thresholds. 


Risk Definitions Specific to Agile 

Adaptive environments are well-suited for projects with a lot of uncertainty, especially where evolving scope ti 

is concerned. You will see as we discuss the Process Groups model for risk management that agile projects (A ) 

can make use of this predictive-based model to a large extent, since all risk management should be done fim 

repeatedly throughout any project. ii 
Let’s start with the reminder that every well-planned agile backlog is a risk-adjusted backlog. Then, because agile 

projects are iterative, teams go through risk identification and analysis, and threat mitigation or elimination for each 

iteration. Additionally, agile continuous improvement practices always include looking for opportunities to deliver as 

much value as possible. Risks are identified in daily standup meetings as team members report any potential impediments 


to their progress. 


Spikes 

Agile teams often explore big risks like new processes or technology using special iterations called spikes. A spike is 
basically a short iteration dedicated to exploring an issue or an approach. A risk-based spike is done before an associated 
increments’ development begins to attempt risk mitigation or elimination—or, enhancement, if an opportunity is 
being explored. 


Example As part of the new library, the staffs stored digital files are being migrated from a shared local area network 
drive to a cloud environment. The biggest risk here, of course, is the loss of files. So the agile team would schedule a risk 
spike to test that the migration will not result in a loss of files. By doing this testing up front, they will uncover issues and 
greatly reduce risk by eliminating discoverable issues. 


Architectural spike 


You may also see this term on the exam. This spike is for proof-of-concept efforts. In our previous example of migrating 
files, an architectural spike may be completed prior to any risk-based spikes. During the architectural spike, the team 
might install new technology or run through how the processes work with the new technology to ensure everything works 
as planned. 
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Fast Failure Riskiest, most impactful efforts are explored as early as possible 


Spikes can induce “fast failure,” and this is 
actually desirable. The earlier failure occurs the 


quicker resources can be diverted to a different 
strategy on a project, or even to a different 
project. The team is basically trying to cause the 
failure if they think there is probability of it 
happening anyway. Assuming they can fix the 
problem, the cost of the failure may be reduced 
if it is fixed early in the project. Figure 12.1 


Late failure comes 
at increased costs 


Early risk-based 
spikes reduce 
cost of failure 


illustrates how fast failure can benefit a project. 


Cost of Failure ————_———_5 


Time ———______5 


Failure gets costlier with time as the built product increases in complexity, 
resources are increasingly used; the cost of change is greater 


FIGURE 12.1 Fast failure 


Risk Management Overview 


As we have in other chapters, we will help you understand the overall Risk Management process by using the Process 
Groups model, as well as include information about risk management methods that are unique to adaptive environments. 
First let’s take a look at how the Risk Management process in the Examination Content Outline (ECO) maps to the same 
process in the Process Groups model. 


The Examination Content Outline and Process Groups Model 


Think About It. In the ECO, domain II, task 3—assess and manage risks—is closely related to the risk 
management process as defined in the Process Groups model. Other tasks that closely align to managing risk 
8 include but are not limited: 


* Domain I (People domain), task 7: Address and remove impediments, obstacles, and blockers for the team 


* Domain II (Process domain), task 15: Manage project issues 


Domain 1 Risk Management Domain 2.7 
Task 7 Measurement 
Address and remove impediments, Plan Risk Management — Domain 2.8 
obstacles, and blockers for the team a 
Identify Risks Uncertainty 
Domain II Perform Qualitative Risk Analysis Planning 


Task 3 


Assess and manage risks Perform Quantitative Risk Analysis 


Task 15 Plan Risk Responses 
Manege polc auan Implement Risk Responses — Executing 


Monitor Risks — Monitoring 
& Controlling 
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Take time to review the ECO and note any additional tasks that may be applicable. 

Example 

+ Risk management may rely on work to Ensure knowledge transfer for project continuity (domain II, task 16). 

+ Ifthere’s conflict on your project, isn’t it a risk to leave it unresolved? The following are also related to risk management: 


v Manage conflict (domain I, task 1) 
V Ensure team members/stakeholders are adequately trained (domain I, task 5) 


What other tasks can you recognize as possibly impacting risk? Taking time to think about this now will help you 
become more familiar with the ECO and be more prepared for the exam. 


The Process Groups model for risk has many parts to it and students love to have an acronym when there are 
many parts to remember. You can remember the following Process Groups model for risk with the acronym 
“PIP P PIM” (Plan-Identify-Perform-Perform-Plan-Implement-Monitor). Or, if you like: “PIQQRIM” 
(Plan-Identify-Qualitative-Quantitative-Responses-Implement-Monitor). 


Figure 12.2 is a visualization of risk management at a high level from the Process Groups model perspective. It can 


help you visualize where you are in the risk management process as you continue with this chapter, and understanding it 
will help you on the exam. 


Key 


4, Continuous change control 
is consistent with all 
approaches 


Change prompts a process 

C to be reiterated through 
progressive elaboration 
or agile methods 


C) 
(e) 
(us) 
> 


Planning 


Remember, 
it's iterative 


—> Changes that cause a 
return to Initiating are rare 


FIGURE 12.2 Risk management process 
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Desired Outcomes of Risk Management 
For the exam, assume that risk management has been properly planned according to the concepts presented in this 
chapter unless a question indicates otherwise. This means the following are built into risk planning, and subsequent risk 


monitoring and risk response implementation: 


Internal and external environmental factors affecting project risks are considered. 

Risk and responses address the inherent uncertainty and complexity on projects. 

Risk related to all possible variables and constraints are accounted for along with their interdependencies. 

There are no huge “fires” to put out every day—they are eliminated with risk response plans. 

Risks are reviewed in every meeting, triggers are monitored, and risks are addressed before they happen. 

Normally, if a risk event does occur, there is a plan in place to deal with it. Hectic meetings to develop responses are a 
rarity and are only needed when an unknown (i.e., unpredictable) risk event occurs and requires the team to develop 
a workaround. 

Risk management helps to limit cost, time, and resource investments on the project. 


There are reserves set aside in the budget for risk events. 


Risk Management Summary 


TRICKS Remember that the Process Groups model describes how and in what order risk management generally occurs 


but project management is iterative and dynamic. Initiating is repeated on large-scale projects when a phase- 


TUA gate system is used. And, of course, on an agile or hybrid project, risk management is considered every time 


the backlog is prioritized for a new iteration, when estimates are created, during release and iteration planning, 


during iteration reviews and retrospectives. 


Plan Risk Management 


The project manager, sponsor, team, customer, other stakeholders, and ex- 
perts may be involved in planning risk management. Part of planning involves 
determining, at a high level, the amount and areas of potential risk on the proj- 
ect. Risk checklists from previous projects can be helpful in planning and 
identifying risks, but risk management is tailored to every project. In practice, 
risk management efforts will differ depending on the size and complexity of 
the project and the experience and skill of the project team. Even how much 
time is spent on risk management is based on the needs of the project. 

The project manager and team evaluate the risk appetites of management 
and other key stakeholders and identify how the team will go about 
performing risk management and who will be involved. Organizational 
process assets like documented procedures and templates related to risk, such 
as standard probability and impact matrices, are identified and adapted. 


When risk management planning is complete, the risk management plan 


may include the following: 


+ Risk strategy This is an overall approach to managing risk throughout the life of the project. 


Methodology This defines how risk management will be performed to meet the needs of the specific project. 
Low-priority or low-risk projects will likely warrant less of a risk management effort than high-priority or high- 
tisk projects. 

Roles and responsibilities This section of the risk management plan explains who will do what risk management 
work. Did you realize that the project manager does not do it all and that stakeholders outside the project team may 
have roles and responsibilities regarding risk management? 

Funding There is a cost of doing risk management, but overall risk management saves the project time and money 
by avoiding or reducing threats and by taking advantage of opportunities. This section includes a plan for utilizing 
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Timing This section specifies when to do risk management depending on estimated timing for the occurrence of 
identified risks. Also note that time needs to be allocated in the schedule for risk management activities. 


Risk categories These are discussed next in the Identify Risks section. 


Stakeholder risk appetite/thresholds The risk appetites and thresholds of key stakeholders are documented and 
considered in the risk management plan. This information is also considered when ranking risks based on probability 
and impacts, and when prioritizing which risks will be addressed in risk response planning. 

Definitions of probability and impact Would everyone who rates the probability of a particular risk a 7 on a 
1 -to-10 scale in qualitative risk analysis mean the same thing? A person who is risk averse might think of 7 as very high, 
while someone who is risk prone might think of 7 as a low figure. The definitions and the probability and impact 
matrix (discussed later in this chapter) help standardize these interpretations and also help compare risks 
between projects. 

Reporting This section of the plan describes what risk-related reports will be created, what they will include, and to 
whom they will be sent. In addition, the composition of the risk register for the project is defined here. 


Tracking The tracking section describes how the risk management process will be audited and how the results of risk 
management efforts will be documented. 


Identify Risks 


In this process, risks to the project and their characteristics are identified. This 
effort should involve all stakeholders and might include literature reviews, re- 
search, and communicating with non-stakeholder subject matter experts. 
Sometimes the core team will begin the process and then other team mem- 
bers will become involved, or there could be a special, dedicated risk team—a 
part of the project team focused on risk management efforts. 


When you get a question about who should be involved in risk 
identification, the best answer is “everyone”! Each type of 
stakeholder has a different perspective of the project and can 
provide thoughts on opportunities and threats. 


Project managers should begin looking for risks as soon as they start on 
the project. In fact, an assessment of overall project risk is included in the 
project charter. The project manager will need good facilitation skills for the 


identification of as many risks as possible. 

It is worth repeating that while risk identification primarily occurs 
during planning, risks are identified throughout the project. For the exam, understand that in a predictive 
environment risk identification is also done during integrated change control, when working with contracts, 
when working with resources, and when dealing with project issues (which are small concerns that may A 
become problems or risks if not resolved). In an adaptive environment, risk identification takes place in Focus 
release planning, iteration planning, and throughout each iteration of building the product. 


Risk Categories 

A standard list of risk categories can help ensure areas of risk are not forgotten. Risk categories are broad, common areas 
or sources of risk that similar projects or other people in the organization have encountered. They can include things like 
technology changes, resource shortages, regulatory hurdles, changes within the internal or external environments, or 
cultural issues. 

Organizations and PMOs should maintain standard lists of risk categories that project managers can use as prompt 
lists to help identify and categorize project risks. When leading risk identification efforts, the project manager should make 
sure each category is considered. 

A risk breakdown structure (RBS) is a hierarchical chart that looks like an organizational chart and can help the 
project manager identify and document risk categories. The following breakdown of risk categories is by no means 
comprehensive but will give you a good understanding of how risk categories work. 
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General Risk Categories 
Research has shown over 300 potential categories of risk, including risks caused by: 


+ The customer 

+ Lack of project management effort (yes, a lack of project management effort adds risk) 
+ Lack of knowledge of project management by the project manager and stakeholders 

* The customer s customers 

+ Suppliers 

+ Resistance to change 

e Cultural differences 


+ External risks, such as regulatory, environmental, or governmental issues; market shifts; problems with project 
sites, etc. 


+ Internal risks, such as changes to schedule or budget; scope changes; inexperienced team members; issues with 
people, staffing, materials, and equipment, etc. 


+ Technological risks, such as changes in technology, technical processes, or interfaces, etc. 
+ Commerical risks, such as customer stability, terms and conditions within contracts, sellers, etc. 


e Unforeseeable risks, which comprise only about 10 percent of risks 


Risks Categories by Project Constraint 
The following sources of risk are specific to project constraints. Each is followed by an example. 


° Schedule “The hardware may arrive earlier than planned, allowing work package XYZ to start three days earlier.” 


e Cost “Because the hardware may arrive later than planned, we may need to extend our lease on the staging area—at 
a cost of $20,000.” 

e Quality “The concrete may dry to our quality standards before winter weather sets in, allowing us to start successor 
work packages earlier than planned.” 


¢ Scope “We might not have correctly defined the scope for the computer installation. If that proves true, we will have 
to add work packages at a cost of $20,000.” 


¢ Resources “Our designer may be called away to work on the new project everyone is so excited about. If that occurs, 
we will have to use someone else, and our schedule will slip between 100 and 275 hours.” 


e Customer satisfaction (stakeholder engagement) “There is a chance the customer will tell us they are unhappy 
with the XYZ deliverable, causing at least a 20 percent increase in time to rework the deliverable and test plans.” 


Business and Pure Risk Categories 
In addition to risk categories, risks can be classified under two main types: 


e Business risk is a risk of a gain or loss for the business 


¢ Pure (i.e., insurable) risk applies only to a risk of loss (such as fire, theft, or personal injury, etc.) 


Variability and Ambiguity 


You may also see references to risks described as “non-event” risks, which fall into the following categories: 


e Variability risks are caused by the inability to predict future changes (e.g., in technology) 


e Ambiguity risks are caused by a lack of understanding (e.g., unclear requirements or expectations) 
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Methods for Identifying Risks 


The primary methods for this process relate to data gathering and data analysis. They include: 


+ Brainstorming + Interviewing 
+ Checklist analysis + SWOT (strengths, weaknesses, opportunities 
* Documentation reviews and threats) 


e Root cause analysis 


Checklist analysis is most often used with risk category prompt lists discussed earlier. Root cause analysis is often 
carried out using a cause-and-effect diagram (like a Fishbone diagram, also known as a “Why-why” or Ishikawa diagram). 
Root cause analysis leads to reorganizing identified risks by their root causes to help find more risks. 


Agile Project Pre-Mortems 


A project pre-mortem is a risk identification method commonly used by agile teams. Here, the project 


manager asks the team to imagine that the project (or iteration) has failed. The team identifies where and A 
why the project might have failed and generates a list of potential failure points. They then troubleshoot the Agile 
plan to attempt avoidance or mitigation of identified causes for failure. A pre-mortem typically involves Focus 


these steps: 
1. Imagine the failure 
2. Generate reasons for the failure 
3. Consolidate the list 
4. Revisit the plan 


Example Remember our example of files being transferred to the cloud? If the project manager holds a pre-mortem, 
the team can identify potential issues that would cause files to be damaged or lost in the transfer process. Once those issues 
are identified, they can generate reasons for the failure and try to solve the reasons or mitigate the impact should the ones 
they can’t solve occur. 


Artifacts of Identify Risks: Risk Register 

The risk register is the main artifact resulting from the Identify Risks process. Think of the risk register as the central 
document for the entire risk management process that will be continually updated as the risk management processes are 
completed and the project continues. 


TRICKS Notice that the risk register is a project document update for several risk management processes. Read exam 


(Mji questions carefully and remember that the risk register contains different information at different points in the 
project management process. 


Example If the project has just started and you are in the Identify Risks process, the risk register will contain the 
identified risks and potential responses, not selected response plans, which come later. 


The risk register at this point in the risk management process includes the list of risks and also may contain potential 
risk responses and their potential risk owners responsible to manage assigned risk responses, root causes of risks when they 
have already been identified, and updated risk categories. Other information that can be documented in the risk register 
includes risk triggers (defined later in this chapter), potential impacts, when each risk could occur, and when each risk will 
no longer present a threat or opportunity. 


TRICKS A tricky question on the exam might ask, “When in the risk management process are risk responses 
(Mji A documented?” The answer is both during Identify Risks (as potential responses) and during Plan Risk 
IEMA Responses (as selected responses). 
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Perform Qualitative Risk Analysis 


As the project manager begins this process, they should have a long list of 
risks documented in the risk register from the Identify Risks process. It 
would be neither efficient nor effective to plan responses to all of them, so 
they need to prioritize those that need planned responses in case they should 
occur. Qualitative risk analysis is the first of two steps in deciding which 
risks need planned responses. It involves subjectively analyzing all identified 
risks for their probabilities and impacts on the project. 

Along with the risk register, the project management plan (including 
the risk management plan), project documents, and organizational 
influencing factors are important contributions to the Perform Qualitative 
Risk Analysis process. Once we have completed assessing risks qualitatively, 
we can decide which of these risks will move on to the second ranking step: 
quantitative risk analysis. 


Qualitative versus Quantitative Analysis 
Many people confuse these two types of analysis. Remember for the exam that qualitative risk analysis is a subjective 


evaluation. In predictive environments the numbers used to rate each risk are usually based on a scale of 1-5 or 1-10. For 
example, if a risk has a high probability of happening it will be a 3 or 4 as opposed to the lower probability of 1 or 2. This is 
just an example, however. The meaning of the scale is created and agreed upon by the team, making it subjective. 

In contrast, quantitative risk analysis is based on a measurable rating like cost and time. The rating of each risk is based 
on an estimate of the actual probability and the actual monetary value at stake (impact). For example, the rating for a risk 
in qualitative analysis might be established as a probability of 3, multiplied by an impact of 4, equaling 12 
(or 3 x 4 = 12). The same risk would be quantified as a probability of 65% times a cost of $40,000 equaling $26,000 
(or .65 x $40,000 = $26,000). 


TRICKS Many people forget which risk analysis is done first: qualitative or quantitative. An easy way to remember this 
is by thinking of the order in the alphabet in which the first unique letter of each word occurs. The letter “L” 


comes in the alphabet before the letter “N”: Qualitative comes before quantitative. 


Methods for Qualitative Risk Analysis 
Data collection and analysis methods specific to this process include a risk data quality assessment, further use of the risk 
categorization discussed earlier, a probability and impact matrix, and analyses of other risk parameters. 


Risk Data Quality Assessment 
With this we assess the information available on a given risk for accuracy and reliability to determine if the risk is valid and 
whether more research is needed to understand it. 

Example Imagine you receive a short risk description anonymously that doesn’t include a lot of data. You may allow 
anonymous contributions during risk identification, but all identified risks must be defined well enough to perform a 
qualitative assessment. 

Risk C Da 

Assigning risks to categories may be helpful when planning risk responses. It’s also important to know that a risk 
breakdown structure allows a project manager to represent risk sources into a chart-like structure, which can help answer 
questions like “What will we find if we regroup the risks by category? By source? By work package?” 

Using risk categories may also allow a project manager to eliminate several risks at once. Think about how useful it 
would be to have not only a subjective assessment of the total amount of risk on a project, but also a breakdown of the risks 
that shows which work packages, processes, people, or other potential causes have the most risk associated with them. 
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Probability and Impact Matrix 
This is a data representation method to plot risks visually to help determine which risks to move forward to quantitative 
risk analysis. Common subjective analysis scales include Low, Medium, High, and | to 5 or | to 10 ratings. 

Example Risks and their rankings are shown in figure 12.3. The product of probability and impact equals the rank. 
As shown in figure 12.4, the probability and impact values can also be plotted on a matrix showing values from higher to 
lower along the vertical and horizontal axes. 

A diagonal line is then drawn through the center. Risks to the right of the diagonal line call for more attention. Many 
or all will be moved forward to Quantitative Risk Analysis. 

Note: The numbers in the Rank column of figure 12.3 can be deceiving without further analysis. Risks A and D are 
very close in rank and their ranks are relatively low. However, risk As impact is not tolerable. You can see that using a matrix 


helps with this type of analysis. 


# Risk 


ja | Hurricane during installation 


XYZ system will arrive late causing a two-week 
delay in deliverable Q. 


D Project will interfere with Morgan's daily work 4 


FIGURE 12.3 Risks and their Rankings FIGURE 12.4 Probability and impact matrix 


Because qualitative risk analysis is a subjective evaluation, organizations frequently define a standard rating system to 
foster a common understanding of what each risk ranking means, as shown in figure 12.5. 


Probability Scale Impact Scale 
Rating Interpretation Rating Definition 
1 Low 1 No real impact 
2 Medium 2 Small to medium reduction of time or cost reserves 
3 Medium-High 3 Medium to large reduction of time or cost reserves 
4 High 4 Over budget or behind schedule or both (0-15%) 
5 Fact 5 Unacceptably over budget or behind schedule or both (over 15%); 


possible physical danger or project failure 


FIGURE 12.5 Ranking definitions for probability and impact 


Risk Parameters Assessments 
In addition to creating a short list of risks, qualitative risk analysis includes identifying risks that should move more 
quickly than others through the process due to factors that are referred to as risk parameters. Some examples of risk 


parameters include the following: 

e Urgency This parameter indicates if the risk is likely to occur soon (requiring the response to be implemented 
quickly) or if the risk requires a particularly long time to plan a response. Urgent risks may be moved directly or more 
quickly into risk response planning. 

¢ Dormancy This is the anticipated time between when a risk occurs and when its impact is felt. 

e Manageability and controllability This parameter indicates the level of difficulty involved in dealing with an 
identified risk, should it occur. 

e Strategic impact This is the degree to which the occurrence of a risk would affect the strategic goals of the 
performing organization. 
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TRICK Qualitative risk analysis can be used for project management tailoring to do the following: 


OF THE i Compare the risk of the project to the overall risk of other projects. 


TRADE 


+ Determine whether the project should be continued or terminated. 


+ Determine whether to proceed to the Perform Quantitative Risk Analysis or Plan Risk Responses processes 
(depending on the needs of the project and the performing organization). 


Artifacts of Qualitative Risk Analysis 


When this process is complete, there will be updates to the following artifacts: 


+ Project management plan (including the risk + Risk register (updated with qualitative analysis data) 
management plan) ise log 
+ Project documents e Watch list 


+ Assumptions log 
+ Risk report 


The risk report will include the results of risk prioritization thus far, including a list of the highest-ranking lists to be 
moved forward to the Quantitative Risk Analysis process. Those risks that do not move forward to Quantitative Risk 
Analysis will moved to a watch list. 


Perform Quantitative Risk Analysis 


The Perform Quantitative Risk Analysis process involves analyzing the prob- 
ability and impact (the amount at stake or the consequences) of risks that 
ranked highest in qualitative risk analysis. The numbers used in this case are 
based on monetary estimates of the time and costs, should a risk happen. 
Quantitative risk analysis also looks at how risks could affect the objectives 
of the project. The purpose of quantitative risk analysis is to determine: 
e Which risk events warrant a response plan and which require the 
most attention. 
e Overall project risk (risk exposure). 
+ The quantified probability of meeting project objectives. 
Examples “We have an 80 percent chance of completing the 
project within the six months required by the customer,” or “We have 
a 75 percent chance of completing the project within the $800,000 
budget.” 
+ Cost and schedule reserves. 


+ Realistic and achievable cost, schedule, or scope targets. 


For some projects, there may be a subset of risks identified that require quantitative analysis. While the project 
manager should always do qualitative risk analysis, they should proceed with quantitative risk analysis only if it is worth the 
time and money; otherwise they should move directly to risk response planning. 

The Perform Quantitative Risk Analysis process can include a lot of calculation and analysis. Luckily, the details of 
these efforts are not a focus of the exam. You need to know that the following actions are part of quantitative risk analysis 
but not how to do them beyond what is explained in this chapter: 

+ Further analyze the highest-ranked risks on the project and other results of qualitative analysis. 

e Perform data analysis to determine which risks have the most impact on the project. 


+ Determine how much quantified risk the project has through data analysis. 
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Methods for Quantitative Risk Analysis 


Quantitative probability and impact can be determined in a variety of ways that make use of some or all the following tools: 


+ Expert judgment from the team and risk specialists © Initetgrqrecnoaiad rach detaans|siti$!s 
+ Data-gathering techniques, such as interviewing +*CoSbahdmdsetatiubs tntiatiagng 
+ Data analysis techniques, such as sensitivity analysis UK sef hfstostioribat conds dst prprinio ps pentscts 


and decision tree analysis 


Simulations 

These techniques can be extremely valuable. Monte Carlo analysis is a simulation in which schedule and cost estimates are 
used to “perform” the project many times to simulate results. Traditionally, there has been only one or two questions 
about Monte Carlo analysis on the exam. 


You do not need to have direct experience performing Monte Carlo analysis for the exam. You should just 
understand that Monte Carlo analysis: 


+ Evaluates the overall risk in the project 

* Is done with a specialized computer application 

+ Determines the probability of completing the project on any specific day or for any specific cost 

* Determines the probability of any activity actually being on the critical path 

* Considers path convergence (points in the network diagram where many paths converge into one activity) 

* Translates uncertainties into impacts to the project 

* Can be used to assess cost and schedule impacts 

* Results in a probability distribution (in the form of a chart) 

Sensitivity Analysis 

This technique analyzes and compares the potential impacts of identified risks. A tornado diagram may be used to 
graphically depict the results of this analysis. Risks are represented by horizontal bars. The longest and uppermost bar 


represents the greatest risk, and progressively shorter horizontal bars beneath represent lower-ranked risks. The resulting 
graphic resembles a funnel cloud, or tornado, as shown in figure 12.6. 


Server installed by November 1 ME 
Data security test MEE 

User training by January 15 p 
Integration testing of code modules ea 
System install on test computers = 

User acceptance test S| 

User screen requirements q 


$-30,000 $-20,000 $-10,000 0 $10,000 $20,000 $30,000 $40,000 


FIGURE 12.6 Tornado diagram 


Expected Monetary Value (EMV) _ 


This is an important method for quantitative risk analysis. EMV can be used in several ways but is often used to estimate 


the impact of a risk by calculating the product of its estimated probability (as a percentage) times its estimated cost (as a 
dollar amount, should it occur). The equation for EMV is: 

EMV=PxI 

Example 65% x $40,000 = $26,000. In other words, a 65% probability of risk that would cost $40,000 if it happened 
has an EMV of $26,000. 
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EMV estimates for risks in a quantitative risk analysis are summed to calculate contingency reserves. Questions on 
the exam may ask “What is the expected monetary value of the following?” Do the following exercise to give this a try. The 
exam could also ask you to calculate the expected monetary value for cost, the expected value (or just “value”) for the 


schedule of a path, or the value of your decision. 


Note that for opportunities, expected monetary value is presented as a positive amount (e.g., $3,000), while threats 


are presented as negative numbers (e.g., -$3,000). 


12.1 Exercise 
In your Exercise Notebook, calculate the expected monetary value for each of these work packages. The math is 
not difficult but completing this exercise will help you remember this calculation for the exam. 


Work 
Package 
A 
B 
e 
Answer 
Work 
Package 
A 
B 
c 


Probability 
10% 
30% 
68% 


Probability 
10% 
30% 
68% 


Decision Tree Analysis 


Impact 


$20,000 
$45,000 
$18,000 


Impact 
$20,000 
$45,000 
$18,000 


Expected Monetary 
Value 


Expected Monetary 
Value 
$2,000 
$13,500 
$12,240 


There have historically been only one or two questions about decision trees on the exam, but since they are unfamiliar to 
many people we will talk about them here. You should know what a decision tree is and be able to calculate a simple one 


from data within an exam question. 


A decision tree is analyzed by calculating the value of each branch (another way of using EMV). The outcome of this 
calculation will show the best option to select. You should also know the following about decision trees: 


+ They consider future events. 


+ They calculate the expected value (probability multiplied by impact) in more complex situations. For example, a 


+ They involve mutual exclusivity. 


determine the best option. 


question so you can correctly interpret the answer. 


don’t get confused when you look at examples of decision trees. Pay attention to the data provided in the 


project manager could evaluate the costs or schedule impheations and benefits of several risk responses at once to 


Some examples of decision trees have the costs occurring only at the end of the project, while others have 
costs occurring early or in the middle of the project. Because a decision tree models all the possible choices to 


resolve an issue, costs can appear anywhere in the diagram, not just at the end. When you are taking the exam, 
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The following exercise includes a decision tree analysis. The box represents a decision to be made, and the circles 
represent what can happen as a result of the decision. 


12.2 Exercise 


A company is trying to determine if prototyping is worthwhile on a project. They have come up with the following 
impacts (see the diagram) of whether the equipment works or fails. Based on the information provided in the 
diagram, what is the expected monetary value of each option? Which is the cheaper option—to prototype or not 
to prototype? Do the calculations and write the answer in your Exercise Notebook. 


z Failure: 35% probability 
noe $200,000 and $120,000 impact 


Pass: No impact 


Failure: 70% probability and 
$450,000 impact 

Do not prototype: 
Setup cost $0 


Pass: No impact 


Answer 


If you just look at the setup cost of prototyping, it would seem like an unwise decision to spend money on 
prototyping. However, the analysis proves differently. Taking into account only the one future event of whether the 
equipment works or fails, the decision tree reveals that it would be cheaper to do the prototyping. The expected 
monetary value of prototyping is $242,000; the expected monetary value of not prototyping is $315,000. 


35% x $120,000 = $42,000 


POSEN Ie $42,000 + $200,000 = $242,000 
Do Not 

70% x $450,000 = $315,000 
Prototype 


TRICKS Project management saves time and money on projects. Getting your organizations executives to understand 
(0J: that fact can be difficult at times. How beneficial would it be if you could prove the value of project management? 


Example Imagine that you have just calculated the EMV of all high-ranking and high-priority risks in 
qualitative risk analysis, or that you have completed a Monte Carlo analysis for a project. In either case, you calculate that 
you need a $98,000 contingency reserve on the project to adapt for risks. Then, when the team moves on to the Plan Risk 
Responses process (discussed next) they eliminate some risks and reduce the probability or impact of others. The EMV 
calculation or Monte Carlo analysis is redone, showing a revised need for a $12,000 reserve. You have potentially saved 
$86,000 before project work even starts! 
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Artifacts of Perform Quantitative Risk Analysis 
The Perform Quantitative Risk Analysis process results in updates to the risk register and other project 
documents, including: 
e Prioritized list of quantified project risks What risks are most likely to have a negative effect on the critical path? 
What risks need the most contingency reserve’? 
¢ The quantified probability of meeting project objectives 
Examples “We have an 80 percent chance of completing the project within the six months required by the 
customer,” or, “We have a 75 percent chance of completing the project within the $800,000 budget.” 


e Quantitative risk analysis trends As the project manager repeats quantitative risk analysis in project planning and 
when changes are proposed, they can track changes to the overall project risk and see trends. 
e Initial contingency time and cost reserves needed (finalized in Plan Risk Responses) 
Example “The project requires an additional $50,000 and two months of time to accommodate the project risks.” 


e Assessment of overall project risk exposure Use overall project success probability (how likely it is that the 
project will achieve all key objectives) and any variables that may still affect the project to fully understand the overall 
risk exposure of the project. 


e Possible realistic and achievable completion dates and project costs, with confidence levels, versus the time and 
cost objectives for the project. 
Example “We are 90 percent sure that we can complete this project on May 25th for $989,000.” 


* Recommended risk responses After quantitative risk analysis is performed, the risk register may include suggested 
responses to overall project risks and individual project risks. 


Plan Risk Responses 


The Plan Risk Responses process involves figuring out, “What are we going 

to do about each top-ranked risk?” We have and will use the risk register, 

which has been updated throughout the risk management process and now 

includes the analyzed and prioritized risks. The “Top Risks” are the risks for 
which responses will be planned. The project manager will use methods like 
alternatives analysis and cost benefit analysis to evaluate the values of vari- 
ous response strategies and specific risk response plans relative to their costs. 

The cost baseline will describe a contingency reserve that will be used in 
addressing these specific risks. See the discussion on reserves later in this 
chapter. 


Responses for Top Risks 
The projects tisk responses may include doing one or a combination of the 
following for each top risk: 


+ Do something to eliminate the threats before they happen. 
+ Do something to make sure the opportunities happen. 

+ Decrease the probability and/or impact of threats. 

+ Increase the probability and/or impact of opportunities. 


This is what risk management is all about. There are always options to respond to risks. If a change to a team members 
availability is a top risk, the project manager can investigate the possibility of replacing that team member with another 
resource with similar skills. If a work package is causing a large amount of risk, the project manager might look at: 


+ Changing the deliverable * Changing the quality requirements 
+ Modifying the work to produce it + Removing scope from the project 
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Responses for Residual Risks 


Residual risks are those left in the project that cannot be anticipated or planned for. Every project has them. For the 
remaining (residual) threats that cannot be eliminated or exploited: 


+ Do something if the risk happens (contingency plans). Contingency plans should be measurable so the project 
manager can evaluate their effectiveness. 


* Do something if contingency plans are not effective or are only partially effective (fallback plans). 


The project manager and the team determine what to do about each of the residual risks—those that cannot be 
eliminated or exploited. This might mean accepting these residual risks, or planning additional risk responses. The work 
involved in all risk responses is then assigned to risk owners. 


en taking the exam, assume that all major potential problems and opportunities that cou ave been 
TRICKS Wh aking th th II jor p ial probl d oppi iti hi ld hi b 

[$ anticipated as risks were identified and analyzed before they occurred and that there was a plan for each risk. 

pated k: dentified and analyzed befi hey d and that thi plan fe h risk. 

il Æ With this in mind, the best answer to a question describing a major problem on the project will be the choice 

that talks about implementing a contingency plan, rather than one that involves discussing possible solutions 

lto a problem after it has occurred. Many people have said that these types of questions were the reason they failed the 

exam. They simply made the wrong choices in situational questions. Be sure to make the transition to this way of thinking 

if it is unfamiliar to you. 


However, no matter how much risk analysis and response planning is done, there is usually residual risk on a project. 
This is why there is a management reserve as well as a contingency reserve. 


Here are a couple more points that can be tricky on the exam: 


e Can all threats be eliminated on a project? Remember that threats can be eliminated and opportunities exploited, but 
the time and trouble involved in eliminating all the threats and exploiting all the opportunities on a project would 
probably not be worthwhile. 


+ Did you know that qualitative risk analysis, quantitative risk analysis, and risk response planning occur throughout the 

life of a project? As noted in other parts of this book, planning is iterative. The project manager needs to review risks 
throughout the project, including while the project work is being done or when checking results. Newly identified 
risks need to go through the risk planning process. 


Risk Response Strategies 

When completing risk response planning, a thorough analysis must be done of the potential responses for each risk. Some 
of these risk response strategies, also known as risk mitigation strategies or strategies for threats and opportunities, involve 
changing the planned approach to completing the project, including changes to the WBS, the quality management plan, 
resources, schedule, budget, or communications strategies. 


Response Strategies for Threats 
The risk response plans the project manager has for specific risks are called contingency plans. The types of response 
strategies for threats include: 


e Avoid This means eliminating the threat by eliminating the cause. Examples include removing a work package or 
changing the person assigned to do work. Avoiding a threat might even involve expanding the scope of the project. 
Example Imagine there’s an estimated 75 percent likelihood of a threat occurring, but an additional level of 
testing or an additional activity would likely prevent this threat. Expanding the scope of the project in this way could 
help avoid the threat. 


On an overall project level, if the threat is beyond the organization's risk threshold, the project manager will need to 
take action to make the project acceptable. This could include removing pieces of the project that are too risky to avoid or 
cancelling the entire project. 


¢ Mitigate This is reducing the probability and/or the impact of threat, thereby making it a smaller risk and possibly 
removing it from the list of top risks on the project. Options for reducing the probability are considered separately 


from options for reducing the impact. Any reduction will make a difference, but the option with the most probability 
and/or impact reduction is often the option selected. 
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Transfer (deflect, allocate) Think “insurance.” This is done by purchasing insurance, performance bonds, 
warranties, or guarantees, or by outsourcing the work, making an outside party responsible for managing the risk. 
There is a strong connection here between risk and procurement (contracts). When proper project management is 
done, risk analysis is completed before a contract is signed, and transference of risk is included in the terms and 
conditions of the contract. 


Avoidance and mitigation are generally used for high-priority, high-impact risks. Transference, along with escalation 
and acceptance (discussed next) may be appropriate for low-priority, low-impact risks as well as those with higher impact. 


Pure risk A response to pure risks—such as fire, property damage, or personal injury—is transference, or purchasing 
insurance. Insurance exchanges an unknown cost impact of a known risk for a known cost impact. 

Example With a risk of fire, the cost impact of the risk is unknown. But when insurance is purchased, the cost 
Transferring the risk by 


impact of the risk of fire becomes known; it is the cost of the insurance and the deductible. 
purchasing insurance does not eliminate all impacts. There may still be residual risks. A project could experience 
schedule delays due to a fire even if fire insurance was purchased, or the cost of the fire damage could exceed the 
amount of insurance purchased. 

Secondary risk In another example, there is a risk that the risk response plan itself could cause a problem. If the third 
party (insurance company or seller) has trouble delivering on their end, they could cause a schedule delay. The project 
manager still needs to decide what to do about any possible secondary risks. 


Response Strategies for Opportunities 


The choices of response strategies for opportunities include: 


Response strategies for both threats and opportunities include: 


Exploit (the reverse of avoid) Either add work or change the project to make sure the opportunity occurs. This 
could be on the individual project risk level or on the overall project risk level. 


Enhance (the reverse of mitigate) Increase the likelihood (probability) and/or positive impacts of the opportunity 
occurring. This could be related to the overall approach to scope and schedule, resources used, or project replanning, 
as well as to individual project risks. 
Share Allocate ownership or partial ownership of the individual or overall project opportunity to a third party 
(forming a partnership, team, or joint venture) that is best able to achieve the opportunity. 
Example It is common in a procurement contract to offer a bonus or incentive to complete the seller’s part of the 
project early if it creates an equal or better savings opportunity for the buyer. 


Escalate If it is outside the scope of the project or beyond the project manager 5 authority, a risk should be escalated 
within the organization. These risks are typically managed at the program or portfolio level. An escalated risk needs to 
be accepted by the program or portfolio manager; the escalation is then documented and the risk is no longer 
monitored at the project level. 


Accept Passive acceptance means to do nothing and to essentially say, “If it happens, it happens.” This leaves actions 
to be determined as needed (workarounds) if the risk occurs. Active acceptance involves creating contingency plans 
to be implemented if the risk occurs and allocating time and cost reserves to the project. 


Common Response Strategies for Threats or Opportunities 
The following rules and strategies can be used for threats and opportunities: 


. 


. 


Strategies must be timely. 

The effort selected must be appropriate to the severity of the risk. Avoid spending more money to prevent the risk 
than the cost of the impact of the risk had it occurred. 

One response can be used to address more than one risk. 

More than one response can be used to address the same risk. 

A response can address the root cause of risk and thereby address more than one risk. 


The team, other stakeholders, and experts should be involved in selecting a strategy. 
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Watch out for questions on the exam about communicating risk-related information! Risk response strategies must 


be communicated to the sponsor, management, and stakeholders. These parties will need to know that you are in control 
of the project even if there is a problem, and they may need to approve the resources to make the risk response strategies 


happen. Communicating about risk is essential for gaining buy-in to the strategy. 


12.3 Exercise 


Now let’s see if you can apply what you have learned. Identify the type of risk response strategy (avoid, mitigate 


the probability, mitigate the impact, transfer, exploit, enhance the probability, enhance the impact, share, escalate, 


or accept) being described. Write the answer in your Exercise Notebook for each description. 


Risk Response 


Description Strategy 
1. Remove a work package or activity from the project. 


2. Assign a team member to frequently visit the seller’ s manufacturing 
facilities to learn about problems with deliveries as early as possible. 


3. Move a work package to a date when a more experienced resource is 
available to be assigned to the project. 


4. Begin negotiation for the equipment earlier than planned so as to 
secure a lower price. 


5. Outsource a work package so as to gain an opportunity. 


6. Notify management that there could be a cost increase if a risk occurs 
because no action is being taken to prevent the risk. 


7. Remove a troublesome resource from the project. 
Provide a team member who has limited experience with additional 
training. 
9. Train the team on conflict resolution strategies. 
10. Outsource difficult work to a more experienced company. 
11. Ask the client to handle some of the work. 
12. Prototype a risky piece of equipment. 


13. Notify the PMO that the testing software needed for the project could 
be used by three other IT groups if the enterprise solution is 
purchased. 

14. The team adds a risk spike to see if a new, less expensive, cloud 
provider could support the product. 
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Answer 
Risk Response Strategy 
1 Avoid 6 Accept 11 Transfer 
2 Mitigate the impact 7 Avoid 12 Mitigate the probability 
3 Exploit 8 Mitigate the probability 13 Escalate 
4 Enhance the impact 9 Mitigate the impact 14 Exploit 
S Share 10 Transfer 


Potential risk response strategies and contingency plans must be analyzed to determine which strategy or 
strategies are most cost-effective and most likely to address the risk. Cost-benefit analysis and multicriteria 
analysis are techniques to evaluate and rank potential risk responses. You may see a question on the exam 
asking you to compare the cost effectiveness of various risk response options. 


Artifacts of Plan Risk Responses 


Planned risk responses may require changes to management plans that have been drafted in planning—at the overall 
project risk level as well as at the individual project risk level. Other artifact updates as a result of planning risk responses 
may include: 


+ Risk register (see below) + Assumptions log 

* Cost forecasts * Lessons learned register 

+ Project schedule * Project team assignments (roles and responsibilities) 
+ Change requests + Stakeholder engagement strategy 

* Quality metrics e Risk report 


* Communications management plan 


Risk Report 


This is updated to communicate the risks of greatest threat or opportunity, overall project risk exposure, anticipated 


changes, and anticipated outcomes of planned risk responses. The concepts defined next relate to the risk register updates 
resulting from Plan Risk Responses. 
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Risk Register Updates 
The risk register is updated to add the results of risk response planning, including: 

e Residual risks After risks have been avoided, exploited, mitigated, enhanced, transferred, shared, escalated, and 
accepted (and related contingency and fallback plans have been created), there will still be risks that remain. The 
known residual risks that are passively accepted should be documented and reviewed throughout the project because 
their rankings may need to change. 


¢ Contingency plans These plans describe the specific actions that will be taken if the opportunity or threat occurs. 


¢ Fallback plans These plans are specific actions that will be taken if the contingency plans are not effective. Think 
how prepared you will feel if you have plans for what to do if a risk occurs and what to do if the original plan does 
not work. 


e Risk owners Each risk must be assigned to someone who will help lead the development of the risk response and 
who will be assigned to lead the risk response or “own” the risk. The risk owner can be a stakeholder other than a team 
member. Think about how the application of risk management could change real-world projects. The risk occurs; the 
risk owner takes the pre-approved action determined in project planning and informs the project manager. No 
meeting is needed—just action! This can be very powerful. 


e Secondary risks Any new risks created by the implementation of selected risk responses should also be analyzed as 
part of risk response planning. Frequently, a response to one risk will create the possibility of new risks. For example, 
if a portion of the project work is outsourced to a seller because the project team does not have the expertise to 
complete the work efficiently, there may be a secondary risk of the seller going out of business. The discovery of 
secondary risks may require additional risk response planning, including ensuring that the secondary risks are of a 
lower severity than the primary risk. 


e Risk triggers These are events that trigger the contingency response. The early warning signs for each risk on a 
project should be identified so risk owners know when to take action. 


e Contracts Before a contract is finalized, the project manager should have completed a risk analysis and included 
contract terms and conditions required to mitigate threats and enhance opportunities. Any contracts issued to deal 
with risks should be noted in the risk register. 


e Reserves (contingency and management) Having reserves for time and cost is a required part of project 
management. We explain these further next. 


Contingency and Management Reserves 
Reserves are covered in the “Budget and Resources” chapter, but let’s look at them again here. Time and cost each have 
two types of reserves: contingency reserves and management reserves. Contingency reserves account for “known 


unknowns” (or simply “knowns”); these are items identified during risk management. Management reserves account for 
“unknown unknowns” (or simply “unknowns”); these are items the project manager did not or could not identify during 
risk management. 


Projects can have both kinds of reserves. As shown in the diagram in figure 12.7 (also shown in the “Budget and 
Resources” chapter), contingency reserves are calculated and become part of the cost baseline. Management reserves are 
estimated (for example, 5 percent of the project cost), and these reserves are then added to the cost baseline to get the 
project budget. The project manager has control of the cost baseline and can approve use of the contingency reserves, but 
management approval is needed to use management reserves. The same applies to reserves in the schedule. 

Make sure you understand that reserves are not an additional cost to a project. The risk management process should 
result in a decrease to the project's estimated time and cost. As threats are eliminated or their probability or impact reduced, 
there should be a reduction to the projects schedule and budget. Contingency reserves are allocated for the contingency 
plans and fallback plans to deal with the associated, accepted opportunities and threats that remain after the risk 
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management planning processes have been completed. No matter what the project manager does, risks will remain in the 
project, and there should be a time or cost allotment for them, just as time or cost is allotted to work activities on the project. 


ject estimat $1,250 


A1 A2 no A ps 
a Pees Boy e e ‘o’ 


FIGURE 12.7 Contingency and management reserves create a cost budget 


There may be questions on the exam that ask you to calculate the contingency reserve for several risk events, which 
may be a combination of opportunities and threats. To do this, you must calculate the value of each risk using the equation 
for expected value (P x I). On the exam, you may have to calculate contingency reserves for either schedule (expected 
value) or cost (expected monetary value). But think about this a minute. Let’s use the example for cost impacts to projects. 
Can you just add all the expected monetary value amounts of the opportunities and threats together and come up with one 
grand total for the budget? No! You’ll need to subtract the total expected monetary value of the opportunities from the 
total expected monetary value of the threats. Why? 

Opportunities will save money and time on the project if they occur. This can reduce the cost or schedule baselines. 
Conversely, the threats will add cost and time to the project. 

You’re being told to subtract opportunities here, but weren’t you told earlier that expected value is often presented as 
a positive amount for opportunities and a negative amount for threats? That’s often true when the values are depicted on 
something like a decision tree, so you can easily identify positive and negative outcomes and their overall effect on project 
costs or schedule. But this example is specifically looking to determine how much money or time to set aside for the 
contingency reserves. Threats will require increasing the amount of contingency reserves, whereas opportunities will 
decrease the required reserves. 


The next exercise will give you practice on calculating a contingency reserve. 
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12.4 Exercise 
Imagine you are planning the manufacture of modifications to an existing product. Your analysis has come up with 
the following information. In your Exercise Notebook, calculate the cost contingency reserve for each of the 


following scenarios, and then calculate the total cost contingency reserve for the project. 


Project Data 


1. There is a 30 percent probability of a delay in the receipt of parts, with a cost to the project of $9,000. 

2. There is a 20 percent probability that the parts will cost $10,000 less than expected. 

3. There is a 25 percent probability that two parts will not fit together when installed, costing an extra $3,500. 
4. There is a 30 percent probability that the manufacture may be simpler than expected, saving $2,500. 


5. There is a 5 percent probability of a design defect, causing $5,000 of rework. 


Total Cost Contingency Reserve 


Answer 
You use the expected monetary value calculation (EMV = P x I) to determine the contingency reserve. The answer 
is $1,075 for the total cost contingency reserve. See the following table for the detailed calculations. 


Cost Contingency Reserve Calculations 


1. 30% x $9,000 = $2,700 
Add $2,700 


2. 20% x $10,000 = $2,000 
Subtract $2,000 


3. 25% x $3,500 = $875 
Add $875 


4. 30% x $2,500 = $750 
Subtract $750 


5. 5% x $5,000 = $250 
Add $250 


Total Cost Contingency Reserve = $1,075 


Think About It. Let’s assume this exercise had examples of threats and opportunities to the schedule. If you 
had a 30 percent probability of a 15-day activity delay, the expected value would be 4.5 days, which would be 
added to the schedule. And if the probability of an activity taking 10 days less than planned was 20 percent, 
the expected value would be -2 days. The resulting contingency for these two risks would be 2.5 days. 


If the risk management process is new to you, the following exercise should help you put it all together by looking at 


it in a chart form. 
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12.5 Exercise 
In your Exercise Notebook, create a flowchart of the risk process from Identify Risks through Plan Risk Responses. 


Answer 


Creating this chart will help you check whether you have understood what you have read in this chapter. Your 
flowchart could be different than the following depiction. 


Avoid or 
exploit 
ff Accept 


Create short list oy actively! 


of risks 
Develo; 
(through Reduce Ata Go back and 
garams and \ probability Develo pene Ny Perform 
Sone V and impact of Identify contingency iterations, 
quantile threats; | ———> residualand —> ians and and update 
risk analysis) increase secondary risks mA Identify project 
lidentify probability residual management 
risks and impact of AT plan and 
opportunities secondary Pees š 
risks jocuments 
Create 
watch list ot Accept > paar 
noncritical passively yon 
é risks 
risks 


Escalate overall project 
risks to program or 
portfolio managers 


Agile Risk Responses 
As we have said before, any of the already discussed concepts and methods can be used in any environment. P oe 
In agile and hybrid environments the result of all this this work takes the form of reprioritizing the backlog, ( A 


creating risk response stories, updates to iteration and release plans, and updates to iteration roadmaps. Agile 
Focus 


Risk-adjusted Backlog 


In an agile environment, a projects’ backlog is prioritized not just for features but for the risk responses that have been 
developed for identified risks. In planning each iteration, agile teams seek to balance delivering the highest-value features 
and mitigating the biggest threats that remain on the project. The backlog can now be referred to as a “risk-adjusted 


backlog,” as illustrated in figure 12.8. 
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Risk Severity —-—-—-——————> Feature Priority 
Severity = (Probability x Impact) 


Prioritized 
iture/Risk List 
Prioritized Prioritized Prioritized Foature/Risk Le 
Risk List Mitigation Actions Feature List Must 
High x High Must — ation | 
High x High Must Must 
High x Med Must Must 
e— ~ y 
Med x High Should Should 
Med x Med Should 
= 
Med x Low Should 
Low x Low Could Should 
Should 
—| on | 
Could 


FIGURE 12.8 Risk-adjusted backlog (prioritized feature list) 


Set-based Design 


Another concept in adaptive environments is set-based design. This is just like doing an extensive what-if analysis. Note 
that a tool like decision tree analysis can be used here. Set-based design involves exploring multiple options, or designs, 
early in the project and eliminating the ones that won’t work. It creates flexibility and allows teams to develop knowledge 
as they work through the different options. 

Spend a moment now thinking about how risk response planning might also lead to adjustments to the schedule, cost, 
quality, procurement, communications, and resource management plans, as well as to the scope, schedule, and cost 
baselines for the project. This concept is critical for understanding the impact risk management has on projects, especially 
if you don’t currently do risk management on your projects. 


Think about it. You are nearing the end of the Plan Risk Responses section. Let’s examine some important 
concepts for the exam in this group of questions and answers. Take a few moments to test yourself. 


ca. Question What do you do with noncritical risks? 
Answer Document them in a watch list, and revisit them periodically. 


Question Would you choose only one risk response strategy for each particular risk? For the project 
as a whole? 
Answer No, you can select a combination of choices. 


Question What risk management activities are done during the execution of the project? 
Answer Watching out for watch-listed (noncritical) risks that increase in importance and looking 
for new risks; implement contingency plans if triggers indicate the risk is about to occur 
or is occurring. 


Question What is the most important item to address in project team meetings? 
Answer Risk. 


Question How would risks be addressed in project meetings? 
Answer By asking, “What is the status of risks? Are there any new risks? Is there any change to the 
order of importance?” 
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Implement Risk Responses 


Implementing risk responses is where the value of proper risk management 
becomes most apparent. When the preliminary work has been done well, 
the Implement Risk Responses process can be handled smoothly, since the 
previously documented plans allow for timely and effective responses to 
risk events. 

Throughout the project, the risk register and risk report are reviewed 
regularly, ensuring everyone is aware of potential risks and ready to 
implement the planned responses as needed. Information on triggers 
enables the project manager, risk owner, and team to recognize indications 
that a risk event is imminent. At that point, the risk owner, supported by 
the project manager, leads previously assigned resources in performing 
response activities. The consequences of threats are averted, or 
opportunities are taken advantage of. Risk thresholds are documented in 
the plan along with expected outcomes of risk responses—for example, 


how much should be saved by each planned risk response so the success of 
the implementation can be evaluated. 


Think about it. At the beginning of this chapter we included the story of a project manager who was managing 
a hardware/software installation during a hurricane. Lets’ revisit that example. If the project manager had 
performed proper risk management, he would have had a plan in place to avoid the risk of a hurricane having an 
impact on his project. 

Example Schedule the project to happen before or after the forecasted hurricane. If the project manager and the 
risk owners had actively monitored known risk triggers (such as the results of weather reports including wind speeds 
and the projected path of the hurricane) and then implemented a risk response plan before the hurricane reached the 
area, they could have avoided the danger, rework, delays, and the costs resulting from the hurricane. 


Sometimes carefully developed plans don’t have the expected result. 


Example Let’s assume the risk owner or the project manager in the previous story implemented a risk response 
plan to reschedule the implementation, causing the schedule to be extended. Although the plan was executed as 
intended, the hurricane caused more damage than anticipated, and the schedule had to be extended beyond the 
planned number of days. Such unforeseen results are managed through change requests to the cost and schedule 
management plans. 


Artifacts of Implement Risk Responses 

Project documents are updated as a result of the Implement Risk Responses process. The risk register and risk report are 
updated with information on responses taken, details on how well the responses addressed the risks, and suggested 
changes to future risk response plans. The lessons learned register is updated with what worked and what didn’t work 
when risk responses were implemented. The risk report is updated with changes to the project’s risk exposure and changes 
to planned risk responses. Ongoing issues, such as confusion or disagreement regarding the response as it was 
implemented, are added to the issue log. 
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Monitor Risks 


Risk-related questions on the exam assume that the project manager has 
done proper project management, including assigning risk owners, putting 
contingency plans and reserves in place, and taking actions as outlined in 
the plan—unless data in the question indicates otherwise. The exam also 
assumes the project is substantially less risky with this planning done. If you 
do not have experience using risk management in the real world, spend 
more time in this chapter and practicing with these concepts so you are 
prepared for these exam questions. 

It is during the Monitor Risks process that the project manager will 
evaluate the effectiveness of the risk management plan. In predictive and 
adaptive environments alike, the project manager will make sure that 
proper risk management procedures are being followed and will watch for 
unexpected effects or consequences of risk events. Corrective actions may 
be needed and change requests will be sent to integrated change control, or 
on an agile project additional risk adjustments will be made to the backlog. 

You will find on the RMC Resources page a checklist of actions a project manager needs to take 
in a predictive environment during the Monitor Risks process. Review that checklist to make sure 
you understand each of the actions. You can find it by scanning the code to the right or going to rmcls. 
com/rme-resources. 


Agile Risk Monitoring 


In an agile or hybrid environment, you may update risk burndown charts, review risks in 


RMC RESOURCES 


a retrospective, and ask the project team how plans are going to reduce threats and 
maximize opportunities. Do you need to create any new stories to address new or Agie 
escalating risks? Do you need to engage the product owner in discussions about Focus 


reprioritizing the backlog based on new risk information? 


Methods for Monitoring Risk 


Other work that is part of the Monitor Risks process is outlined in the following sections. 


Workarounds 

If the project has deviated from the baselines, the team may take corrective action to bring it back in line. Recommendations 
for such corrective actions may include workarounds. Whereas contingency responses are developed in advance, 
workarounds are unplanned responses developed to deal with the occurrence of unanticipated events or problems on a 
project (or to deal with risks that had been accepted because of the unlikelihood of an occurrence and/or minimal 
impact). Project managers who do not perform risk management spend a lot of their time creating workarounds. 


Risk Reassessments 

Questions always seem to come up on the exam that require you to know that the team needs to periodically review the 
risk management plan and risk register and adjust the documentation as required. It is important to determine whether 
any changes or adjustments need to be made to what was planned based on information that becomes apparent once 
work begins. Reassessing risk is a good topic for a team meeting, a retrospective, or even a separate meeting, as part of 
risk reviews. 


Risk Reviews and Audits 
For the exam, think of status meetings as team meetings in which the project manager can perform risk reviews and 
risk audits. 

e Risk reviews are held regularly to discuss the effectiveness of planned risk responses that have been implemented on 
the project, and may result in the identification of new risks, secondary risks created by risk response plans, and risks 
that are no longer applicable. Closing of risks allows the team to focus on managing the risks that are still open. The 
closing of a risk should result in the associated risk reserve being returned to the company. 

+ Audits can be performed during meetings to assess how well risk processes are working for the project. The auditing 
process is documented in the risk management plan. 
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Reserve Analysis 


Reserve analysis is a matter of checking to see how much reserve remains and how much might be needed. It is like 
checking the balance in your bank account to ensure your monthly budget is on track. Reserves must be protected 
throughout the project life cycle. 

Now let’s talk about a concept that can be tricky on the exam, especially for those who are not experienced in 
systematically managing risk. People wanting to change the project in response to problems that have occurred may suggest 
using the reserves instead of adding cost or time to the project. It is important to know that a contingency reserve may only 
be used to handle the impact of the specific risk it was set aside for. So, if the change is part of the risk response plan that 
was previously accounted for in the budget, the reserve designated for that response may be used. If it is not, the project 


manager must take preventive or corrective action, fast track, crash, or otherwise adjust the project to accommodate or 
make up for the impact of the problem and its resulting changes, or request new reserve line items. 

Under certain circumstances, usually determined by the project sponsor, management reserves may be used for 
situations that are within the scope of the project but were not previously identified. 

Example Assume that a change to the product order functionality on a website has exposed an unidentified data- 
sharing incompatibility with the real-time data on the legacy inventory management system. A workaround needs to be 
created to keep the project on track. Management reserves will be used to hire experts to fix the problem and keep the 
project close to the current schedule. 

If identified risks do not occur, the associated time or cost reserves are returned to the company, rather than used to 
address other issues on the project. If you are inexperienced with risk management, make sure you understand how 
reserves are used and protected. 


Technical Performance Analysis 
Technical performance analysis uses project data to compare planned versus actual completion of technical requirements 


to determine if there is any variance from what was planned. Any variance could indicate possible risks to the project, 
either opportunities or threats. 


Agile Retrospectives and Risk Burndown Charts N 
Retrospectives and risk burndown charts are agile tools that allow for ongoing monitoring and controlling ( A ) 
for risks. halle 
+ Retrospectives occur throughout an agile project at the end of iterations. Retrospectives offer a number 
of benefits for controlling risk including improved: 


>/ Productivity by identifying and applying lessons learned immediately. 

>/ Capability by providing a venue for spreading scarce knowledge (or tacit knowledge), 

y Quality by finding circumstances that have led to defects and removing the causes. 

y Capacity by finding process improvements, which in turn improve a team’s work capacity. 


* Risk burndown charts may be used for planning, managing, and controlling risk. These charts allow stakeholders to 
easily see a risk profile on a project. Risk burndown charts quickly inform stakeholders whether the threats are moving 
in the right direction (downward), or if they are escalating. See the example in figure 12.9 in which the project team is 
developing library software for patrons who are looking for jobs. Four risks have been identified. 
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The biggest risk is that the “Resume builder” software is not able to make a nice-looking, professional resume because 
it can’t decide where a logical page break should be inserted. The team performs a risk spike in January to try an artificial 
intelligence module to find the best place for the page break. When they succeed, the associated risk is eliminated and in 
turn the overall project risk was reduced by early February. 


18 
16 | Resume builder feature can't 
14 make a logical page break 
x 
w 12 o Resume builder file isn't 
= 10 accepted by hiring companies 
= 8 
x a Interface with job board 
= 6 companies is error prone 
3 4 
ia New features difficult for 
2 patrons to use 
0 
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FIGURE 12.9 Risk burndown chart 


Artifacts of Monitor Risks 


As with other risk management processes, change requests, updates to any project management plan component, the risk 
register, risk report, and other project documents are a result of Monitor Risks, along with additional outputs listed here. 


Work Performance Information 


This is the analysis of the work performance data gathered as part of project control. Examples include: 


+ Results of risk reviews and audits 

+ Performance measurements on schedule progress 

+ Determinations of which risks can be closed or are likely to close in the near future 
+ Variance analyses comparing the planned versus actual risk data 


+ Time and cost of implemented risk responses 


In agile and hybrid environments risk response plans are recorded and carried out as stories in the 
backlog. Information is exchanged in daily standup meetings about new accomplishments as well as impedi- 


Agil 
ments, and is documented through an updated backlog and burnup and burndown charts. = 


Focus 
Risk Register Updates 
The Monitor Risks process will add the following to the risk and lessons learned registers: 

* Outcomes of risk reassessments and risk audits 

+ Results of implemented risk responses 

+ Updates to previous parts of risk management, including the identification of new risks 

e Closing of risks that are no longer applicable 

* Details of what happened when risks occurred 


+ Lessons learned 
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TRICKS Carefully read situational questions 
whether the actual work of the proj 


risks may be identified, or planned 
evaluation of risk processes. 


that describe suggested changes resulting from risk processes to determine 
ect has begun. You will have to determine what efforts are generating the 


change requests to help you evaluate answer choices. If the work of monitoring risks is being performed, new 


risk responses may need to be adjusted based on project knowledge or an 


As a result of approved changes, risk planning must again be performed appropriately, and new risks must be evaluated 
and ranked, which may result in more risk response planning. This will generate change requests to integrated change 


control. The trick here is to remember that the 
to them must go through integrated change control 


Organizational Process Asset Updates 
The Monitor Risks process may include the crea 


approved project management plan and baselines are not static but changes 


tion or enhancement of risk templates, such as the risk register, checklists, 


and risk report, as well as updates to risk management processes and procedures. The project's risk breakdown structure, 


backlog, and other data may be added to OPAs 


as historical records for future projects. Updates to agile project artifacts, 


like new backlog and burndown chart versions, as well as records of planned vs. actual iteration velocities are also 


organizational process assets. 


knowledge of risk management: 


The exam may describe situations where the wrong thing is being done as a way of testing whether you realize 
it is wrong. Some of the following common risk management mistakes can help you consolidate your 


* Risk identification is completed without knowing enough about the project and then not iterated. 


+ Padding of estimates is used instead of the risk management process. 


+ The processes of Identify Risks 


through Perform Quantitative Risk Analysis are blended, resulting in risks 


that are evaluated or judged as they come to light. This decreases the number of total risks identified and 
causes people to end risk identification too soon. 


+ The risks identified are genera 


rather than specific (for example, “communications” rather than “poor 


communication of customer § needs regarding installation of system XYZ could cause two weeks of 


rework”). 


+ Some things considered to be risks are not uncertain; they are facts and are therefore not risks. 


+ Whole categories of risks (such as technological, cultural, marketplace, etc.) are missed. 


+ Only one method is used to identify risks (for example, only using a checklist) rather than a combination of 
methods. A combination helps ensure that more risks are identified. 


+ The first risk response strategy identified is selected without looking at other options and finding the best 


option or combination of options. 


* Risk management is not given enough attention. 


* Project managers do not explain the risk management process to their team during project planning. 


+ Contracts are signed long before ris 


12.6 Exercise 


The Risk Management Process 


There may be many questions about the proces: 


ks to the project are discussed. 


s of risk management on the exam. The following exercise tests if 


you understand what you have read. In your Exercise Notebook draw seven columns with headings of the seven 
processes. Your table can be organized like the following table. Then recreate the risk management process, 
including the outputs. Check your answers against our answers when you are done. You may need to repeat this 


after you have iterated your risk study process. 
for the exam. 


Three attempts usually ensures you know the process well enough 


JH 


Plan Risk 
Management 


Perform 
Qualitative 
Identify Risks Risk Analysis 
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Perform 
Quantitative 
Risk Analysis 


Plan Risk 
Responses 


Risks and Issues 


Implement 
Risk 
Responses 


Monitor Risks 


| 


Answer 


Plan Risk 
Management 


+ Answers the 
following 
questions: 


- How will you 
perform risk 
management on 
the project? 

- What risk 
management 
policies or 
procedures exist, 
and what new 
ones are needed? 


When will the 
processes and 
procedures of 
risk management 
be performed? 


How will risks 
be identified, 
and what tools 
will be used? 


- What are 
stakeholders’ 
roles and respon- 
sibilities for risk 
management? 

- How will you 
budget for risk 
management? 

~ What are the 
appetites and 
thresholds for 
risk? 


Jutputs 


Perform Perform 
Qualitative Risk Quantitative Plan Risk 
Identify Risks Analysis Risk Analysis Responses 
+ Identify all the + Qualitatively + Numerically + Use risk 


risks on the 
project. 


+ Use tools such 
as brain- 
storming, root 
cause analysis, 
documentation 
review, check- 
lists, interviews, 
SWOT anal- 
ysis, assump- 
tions and 
constraints 
analysis, and 
prompt lists to 
facilitate risk 
identification. 


+ Involve and 
engage stake- 
holders in the 
risk manage- 
ment process. 


determine which 
risk events warrant 
a response. 


Assess the quality 
of the risk data. 


Complete a risk 
urgency 
assessment. 


Subjectively deter- 
mine the proba- 
bility and impact 
of all risks. 


Determine if you 
will perform 
quantitative risk 
analysis or proceed 
directly to risk 
response planning. 


Find ways to 
represent the 
analyzed data from 
qualitative risk 
analysis. 


Document the 
watch list (noncrit- 
ical risks). 


Determine the 
overall risk ranking 
for the project. 


evaluate the top 


risks. 


Quantitatively 
determine 
which risks 
warrant a 
response. 


* Determine 


initial reserves. 


Create realistic 
time and cost 
objectives. 


Determine the 
probability of 


meeting project 


objectives. 


response strate- 
gies to decrease 
project threats 
and increase 
opportunities. 


+ Create contin- 
gency and fall- 
back plans. 


+ Determine 
secondary and 
residual risks. 


» Calculate final 
reserves. 


+ Determine risk 
owners (if not 
already done). 


+ Identify risk 
triggers. 


+ Accept or esca- 
late risks, where 
appropriate. 


Implement 
Risk 
Responses Monitor Risks 
+» Implement + Respond to risk 
contingency triggers. 
and fallback D : 
plans (risk * Monitor residual 
owner and risks. 
resources). TRKE 
«Answer workarounds. 
go and + Evaluate effective- 
acilitate 
f plans. 
clarification of p ac 
plan details. * Look for additional 
c itak risks; then qualify, 
+ Communicate A 
eee quantify, and plan 
hold A responses for them 
olders 
according to ARRS: 
the plan. * Revisit the watch 
list. 


Analyze work 
performance data 
and look for 
trends. 


Update plans. 


Communicate risk 
status. 


Close risks. 


Recommend 
changes, including 
corrective and 
preventive actions. 


Perform risk audits 
and risk reviews. 


Perform reserve 
analysis. 
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Risks and Issues 


Plan Risk 
Management 


+ Risk manage- 
ment plan 


TWELVE 


Identify Risks 


+ Risk register 
updates, 
including: 

- List of risks 


m Potential risk 
owners 


- List of poten- 
tial risk 
responses 


+ Risk report with 
summary infor- 
mation on risk 
details and the 
sources of 
overall project 
risk 


Project docu- 
ments updates, 
such as lessons 
learned in the 
identification of 
risks for the 
project, any 
issues, and new 
or existing 
assumption and 
constraint 
information 


Perform 
Qualitative 
Risk Analysis 


+ Risk register 
updates, 
including: 

- Risk ranking 
of the project 
as compared 
to other 
projects 


List of priori- 
tized risks 


Risks by 
category 


Risks needing 
additional 
analysis and 
response 


Watch list 
Data on prob- 
ability and 
impact 
analysis 


Data on risk 
urgency 


- Assumptions 
and 
constraints 
analysis 
updates in 
assumptions 
log 


Perform 
Quantitative 
Risk Analysis 


Outputs 


+ Project docu- 
ment updates, 
including the 
following updates 
to the risk report: 
- Assessment of 

overall project 

risk exposure 

Probability of 

meeting 

objectives 


+ Interpreted 
quantitative 
analysis results, 
such as key 
sources of 
overall project 
risk 

Prioritized list 
of individual 
project risks 


Trends in quan- 
titative risk anal- 
ysis results 


Recommended 
risk responses 


- Initial reserves 


+ Updates to the 
risk register on 
the specific 
analysis for 
individual project 
risks 


Plan Risk 
Responses 


+ Change requests 


+ Updates to the 
project manage- 
ment plan and 
project docu- 
ments, 
including: 

- Assumptions 
log 
- Cost forecasts 


- Lessons 
learned register 


- Project 
schedule 


- Project team 
assignments 


- Risk report 
+ Updates to the 
risk register, 
including: 
- Residual and 
secondary risks 


- Contingency 
and fallback 
plans 


- Risk owners 
- Triggers 

- Final reserves 
- Contracts 


- Accepted risks 


Implement Risk 
Responses 


+ Change requests 
to project manage- 
ment plan, 
including schedule 
and cost baselines 


Updates to project 
lessons learned 
register, including 


the effectiveness of 


risk responses and 
recommendations 
for managing 
future risks 


Updates to the 
issue log regarding 
areas of :onfusion 
or disagreement 


Updates to the risk 

report regarding: 

- Overall project 
risk exposure 
after imple- 
menting planned 
responses 


- Changes to 
planned risk 
responses 


Updates to the risk 
register, including 
data on risk 
response 
implementations 


Monitor Risks 


+ Work perfor- 
mance 
information 


* Updates to the 
risk register and 
other project 
documents, 
including: 

- Outcomes of 
risk reviews and 
audits 


- New risks 
- Closed risks 


- Details of risk 
occurrences 


- Lessons learned 


- Workarounds 


+ Change requests, 
including recom- 
mended correc- 
tive and 
preventive 
actions 


+ Updates to the 
project manage- 
ment plan and 
organizational 
process assets 


+ Updates to the 
risk report 


Putting It All Together 


The responsibilities of risk management are basically the same for both predictive and adaptive environments. But, instead 
of doing all the risk management planning up front, agile teams go through risk identification and analysis and threat miti- 
gation or elimination during release planning and for each iteration. For the exam, make sure you have a clear understand- 


ing of the risk management process and what happens in each process group. 


Don’t forget to review the Quicktest at the beginning of the chapter to identify any gaps in your knowledge. 


The following exercise tests your understanding of threats and opportunities and the type of response, using the 
library case study as an example. 
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TWELVE Risks and Issues 


12.7 Exercise 
For each risk and response below, indicate if it is a threat or opportunity and note the type of response 


being proposed. 
Type of response 
Threat or (mitigate, avoid, 
Risk Opportunity Response enhance, etc.) Probability 
1. New mayor or city council Build strong community Medium 
members decide to cut spending support to decrease 
likelihood. 
2. A wealthy benefactor donates to Meet with potential Low 
have their name on the library benefactors. 
and the city council agrees. 
3. Construction is delayed by Plan inside work for rainy Medium 
weather and material shortages. days; set aside reserves for 
expediating materials if 
necessary. 
4. A coffee shop could bring in Partner with a coffee shop High 
more revenue than expected franchise to run the shop. 
(possibly from people who are 
not even using the library). 
5. A community member forms a Build strong community Low 
group to protest the library support. 
building costs. 
6. A construction worker is injured Make sure all contractor Low 
on the job site and requires workers are covered by an 
medical care. accident insurance policy 


with medical coverage. 
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Answer 
Type of response 
Threat or (mitigate, avoid, 
Risk Opportunity Response enhance, etc.) Probability 
1. New mayor or city council Threat Build strong community Mitigate Medium 
members decide to cut spending support to decrease 
likelihood. 
2. A wealthy benefactor donates to Opportunity Meet with potential Enhance Low 
have their name on the library benefactors. 
and the city council agrees. 
3. Construction is delayed by Threat Plan inside work for rainy Mitigate Medium 
weather and material shortages. days; set aside reserves for 
expediating materials if 
necessary. 
4. A coffee shop could bring in Opportunity Partner with a coffee shop Share High 
more revenue than expected franchise to run the shop. 
(possibly from people who are 
not even using the library). 
5. A community member forms a Threat Build strong community Mitigate Low 
group to protest the library support. 
building costs. 
6. A construction worker is injured Threat Make sure all contractor Transfer Low 
on the job site and requires workers are covered by an 
medical care. accident insurance policy 


with medical coverage. 


12.8 Exercise 
Now let’s look at the library case study using an adaptive approach. The library software system upgrade also has 
some risks. Using the adaptive approach, risks will be planned into iterations as risk spikes or tests. 


Indicate the order in which the following risks should be addressed. 


Risk Response or spike plan Sequence 
The number of users is more A risk spike testing 10,000 concurrent users 
than expected and slows the will be conducted. 


performance of the software. 


Software is not built with The first iteration of the software will include 
adequate cybersecurity a virus scanner which will run daily to detect 
protections and is hacked. potential problems. 

The search capabilities in the The software will collect all terms entered 
software are not adequate for into the Search box and analyze them 

most patrons of the library monthly. 
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Answer 


Risk 
The number of users is more 


than expected and slows the 
performance of the software. 


Software is not built with 
adequate cybersecurity 
protections and is hacked. 


The search capabilities in the 
software are not adequate for 
most patrons of the library 


TWELVE Risks and Issues 


Response or spike plan Sequence 


A risk spike testing 10,000 concurrent users 2 
will be conducted. 


The first iteration of the software will include 1 
a virus scanner which will run daily to detect 
potential problems. 


The software will collect all terms entered 3 
into the Search box and analyze them 
monthly. 


51Q 
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1 3 Procurement 


Introduction 


Many project managers have little experience in procurement, yet the exam will test your knowledge 
on the procurement process and on procurement types. Even experienced project managers may stum- 
ble over the nuances of procurements. For example, an experienced project manager who took an 
RMC class was upset about a situation where he had arranged a meeting with a seller and the seller had 
not shown up. After he rescheduled the meeting, the seller still did not show up. When the instructor 
asked what kind of contract he was working with, the student contacted his office and found out it was 
a fixed-price contract. The instructor then asked where in the contract it said the seller had to attend 
such meetings. The student determined that meetings were not listed in the contract. So, why would a 
seller attend a meeting if he was not getting paid for it? 


oe Think about it. What do you think the project manager’s role is in the procurement process? 


Think about this question as you go through the rest of this chapter. With the project 
managers Tole in mind, think about how the concepts presented apply to your own 
experience. By “imagining into reality ” those things with which you have no direct experience, 
you will be better equipped to answer procurement questions on the exam. 


A project manager should have the basic procurement management skills required, including the 
ability to help create, read, and manage contracts and any supporting documentation. If you have 
worked with contracts before, you might have to fine-tune your knowledge by learning some new 
terms and by understanding the project manager’s role a little better. 


If you have little or no experience working with contracts, you should obtain from your 


company’s contracts, procurement, or legal department some sample contracts, requests 


for proposals, and the resulting sellers’ proposals. Spend time reviewing them. 


Definitions Related to Procurement Management 


Procurement 

Simply put, procurement is a formal process to obtain goods and services. From a project manager’s 
perspective this is the process of creating and maintaining relationships with parties (sellers) to buy 
products and services outside the organization. The project manager also ensures the purchased goods 
or services are integrated into a project’s product. 


Contracts 
Contracts can be written or verbal (although for the exam they should be in writing), are typically 
created with an external entity, and involve an exchange of goods or services for (usually monetary) 


compensation. A contract forms the legal relationship between entities, is mutually binding, and 
provides the framework for how a failure by one side will be addressed and remedied, in court 
if necessary. 
Agreements 
The broader term “agreement” includes documents or communications that outline internal or 


external relationships and their intentions. A contract is a type of agreement, but an agreement isn’t 
necessarily a contract. Imagine that two divisions of a company want to combine resources to achieve 
a shared objective. They would create an agreement, but likely not a contract. Examples of agreements 
that are not contracts are the project charter and plan documents, internal service level agreements, 
memos or letters of intent, letters of agreement, emails, and verbal agreements. 


QUICKTEST 


Contracts vs. agreements 
Buyers and sellers 
Procurement 
Management process 
Centralized/decentralized 
contracting 
Project manager's role 
Contract types 
- Fixed-price 
- Time and material 
- Cost-reimbursable 
- Indefinite Delivery, 
Indefinite Quantity 
(IDIQ) 
Risk and contract type 
Agile Contracts 
- Graduated fixed-price 
- Fixed-price work 
packages 
- Not-to-exceed time and 
material 
- Early termination 
Sharing ratio 
Nondisclosure agreement 
Standard contract 
Special provisions 
Terms and conditions 
Incentives 
Make-or-buy analysis 
Logistics and supply 
chain management 
Source selection analysis 
Procurement SOW 
Bid documents 
Noncompetitive forms of 
procurement 
Bidder conference 
Seller proposal 
Proposal evaluation 
Weighting system 
Independent cost 
estimates 
Presentations 
Negotiations 
Selected sellers 
Closed procurements 
Product validation 
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How the project manager communicates, escalates, and solves problems will vary depending on whether their actions 
are governed by a contract or an internal agreement. Notifying a seller of a default on a contract term or condition should 
be done through formal written communication to create a record and ensure appropriate legal action can be taken if 
necessary. In comparison, failure to meet a term of an internal agreement might be handled in a conversation followed up 
by an email. 

Be prepared to see the terms “contract” and “agreement” on the exam. Understanding whether a situational exam 
question describes an internal agreement or a contract might help you select the right answer. 

In this chapter, we primarily use the term “contract,” because the procurement process is used to acquire necessary 
resources that are outside the project team and involve legal documents between the buyer and seller. 


Buyers and Sellers 


The company or person who provides goods or services may be called a contractor, subcontractor, supplier, designer, or 
seller. The PMBOK* Guide primarily uses the term “seller,” but the exam may use any of these terms. The company or 
person who purchases the goods or services is called the buyer. Many companies are a buyer in one procurement and a 
seller in another. For the exam, assume you are the buyer. 


Procurement Management Overview 
a 


There are many Examination Content Outline (ECO) tasks that overlap with procurement. The following chart illustrates 
that ECO task 8 in domain I and tasks 8 and 11 in domain II map directly to the procurement management process from 
the Process Groups model. For example, part of defining project scope is to determine whether the entire scope can be 
completed internally, or if part of it will be outsourced. This analysis results in make-or-buy decisions, which are directly 
related to project procurements. Managing procurements is in turn essential to managing scope. 

Additionally, efficient communications and stakeholder management, and the effective use of interpersonal and team 
skills, along with conflict management all contribute to procurement management. 


The Examination Content Outline and Process Groups Model 


Think About It. In the ECO, domain IJ, task 11—Plan and manage procurement—is closely related to the 
a procurement management process as defined in the Process Groups model. Other tasks that closely align to 
rs managing procurement include but are not limited to: 


+ Domain I (People domain), task 8: Negotiate project agreements 


* Domain II (Process domain), task 8: Plan and manage scope 


Domain 1 Procurement Management Domain 2.4 
Task 8 Planning 
Negotiate project agreements Plan Procurement Management — Planning Domain 2.5 
Conduct Procurements — Executing Project work 
Domain II a 
Task 8 Control Procurements — Monitoring Domain 2.7 
& Controlling Measurement 
Plan and manage scope 
Task 11 Domain 2.8 
Uncertainty 


Plan and manage procurement 
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Take time to review the ECO and note any additional tasks that may be applicable. 

Example 

+ Execute the project with the urgency required to deliver business value (domain II, task 1) 
+ Manage communications (domain II, task 2) 

+ Assess and manage risks (domain II, task 3) 

+ Support team performance (domain I, task 3) 


+ Address and remove impediments, obstacles, and blockers for the team (domain 1, task 7) 


Can you see how procuring part of the scope of the project can support the team’s performance? Efficient 
communication and stakeholder management certainly apply to procurement management. What other tasks can you 
recognize as impacting procurements (or that procurements impact)? Really, any of the ECO tasks could be applicable 
because as a project manager you are doing all the ECO tasks to plan and manage the project and you are procuring a part 
of the project. Procurements must be integrated completely with the rest of your project. Take time with the ECO to 
consider this. Doing so will help you become more familiar with the ECO and be more prepared for the exam. 

When buying goods or services is part of a project's scope, the project manager facilitates the creation of a plan for 
procurement. This includes a strategy for how each contract will be managed and a description of the work to be done by 
each seller (a procurement statement of work). Procurement management includes planning, conducting, and controlling 
procurements (which may also be summarized as planning and managing procurement), and includes negotiating and 
managing contracts. 


TRICKS For some projects, sellers will provide the full solution, rather than just augmenting a project team with 


additional resources. 


Example You might add contract developers to your internal staff to help code software, or alternatively 
outsource all development work to an external resource who would plan and manage developers, testers, etc. 


Managing procurements requires legal knowledge and negotiation skills. Project managers in most organizations are 
not expected or authorized to lead in legal matters or contract negotiation. You should understand what the procurement 
experts need from you, provide them with that information, and work with them throughout the project life cycle. 


Key 
i Continuous change control 
k is consistent with all 


approaches 


Change prompts a process Planning 
C to be reiterated through 
progressive elaboration 


or agile methods 


«===> Changes that cause a 
return to Initiating are rare 


Remember, 


baller Executing 
it's iterative 


M&C 


FIGURE 13.1 Procurement management process 
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Desired Outcomes of Procurement Management 

The Process Groups: A Practice Guide explicitly states only one direct outcome of planning and managing procurements and 
that is, of course, the effective management of procurements. But there are other outcomes associated with accomplishing 
this effective management. 

As with all processes you should assume for the exam that procurement management has been properly planned 
according to what you learn in this chapter unless a question indicates otherwise. This means the project manager has given 
the following considerations in planning and managing procurements on the project: 

* On each procurement itself, the contractor performs to the plan with efficient and appropriate processes. 

+ Procurements are planned and integrated efficiently into other project constraints, requirements, and deliverables. 

e Changes related to procurement are efficiently and holistically managed with regard not only to scope but to all 

project constraints, through integrated change control and written contract changes as necessary. 


+ Time spent planning and managing procurements are appropriate to each procurement situation. 


Spend a moment reviewing figure 13.1, which shows the procurement management process from the Process Group 
model perspective. This will help you to understand the procurement process in general, and where you are in the process 
as you read the following sections and prepare for plan-driven exam questions. 

Here’s an example of how the procurement process would work. 

Example HeartCare Medical has assigned a project manager to develop an instruction manual for a medical device. 
As part of the development, the instruction manual needs to be translated into ten languages. The company has never done 
translations before. 

+ The English version of the content can be developed in-house. The project manager and team decide the translations 

must be outsourced to a translation company (make-or-buy decision). 

+ Aprocurement statement of work (SOW) is developed and combined with contract terms to document the scope of 

work and legal relationship between the buyer and the seller (or translation company in this case). These are first 
known as bid documents that are later sent to prospective translation companies (sellers). 

+ For the SOW, the procurement department may review the scope of the work for completeness, and the project 

manager might add scope related to project management activities such as specific reporting requirements or required 
attendance at meetings. 


+ The type of bid document used is influenced by the contract type selected and the content within the procurement 


SOW. As you will see later in this chapter, different types of contracts require project managers to focus on different 
areas of management. 

+ The SOW is sent out to the translation companies (prospective sellers). They will review the bid documents, develop 
a full understanding of what the buyer wants, then assess any risks and determine whether they will submit a proposal. 
They may have the opportunity to participate in a bidder conference or a pre-proposal meeting, and may be able to 
submit questions before the proposal deadline. All questions should be in writing and should relate to the bid 
documents. Buyer responses must be shared with all translation companies to ensure that all bids will be based on the 
same information. 

+ If the scope is incomplete or unclear, if a translation company is aware of the buyer having a history of poorly managing 
projects, or if any other risks are identified, a translation company may decide not to respond, or may adjust the price 
and/or schedule submitted to the buyer to account for these risks. 

e Because they are working with a fixed-price contract (a fixed fee is required), the translation companies should 
include these risks in the total detailed cost estimate, as well as other costs, such as overhead, and then add profit to 
come up with a bid or quote. In any case, the risk of the project is formally or informally assessed before sending the 
bid or proposal to the buyer. 

+ After HeartCare Medical (the buyer) receives competing proposals, they may shorten the candidate list or ask for 
presentations from all the candidates. Once presentations are completed, a preferred translation company is selected 
and negotiations take place. These negotiations require the involvement of the project manager. The procurement 
SOW, terms and conditions, and other components of the bid documents are negotiable. Finally, a translation 


"mi 


company is selected, a contract is signed, and other procurement management artifacts are updated accordingly. 
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+ Managing the procurement involves making sure the requirements of a contract are met, controlling the contract, and 
making only approved changes. The procurement department helps the project manager resolve questions such as, 
“What is and is not in the contract?” or “What does a particular section of the contract really mean?” 

+ When the procurement § work is complete and after the buyer accepts the final deliverables (the instruction manual 
in ten languages), the procurement is closed as soon as possible. This can happen within any phase of the project life 
cycle, as the contracted work is completed. For example, the selected translation company (seller) completes the 
Spanish and French translations two months earlier than the other eight languages. If there are separate contracts per 
language, the Spanish and French contracts can be closed. 

e Activities to close out a procurement include an analysis of the procurement process to determine and document 
lessons learned (formally called a procurement audit). Final reports are submitted and final payment is made. 


Could you now describe the procurement process and relationships to someone else? Be sure you understand this 
overview before continuing with the chapter. 


Detailed Outcomes 
The following outcomes should be assured by appropriate attention to procurement management: 


e The project is planned and executed holistically with procured product and service components integrated seamlessly 
into the product of the project. 

+ Procurement audits demonstrate that the procurement processes and procedures used on the project were 
appropriate, or progress toward continuous improvements has been made including documenting what needs to be 
done differently in the future. 

+ Project management assures that contract specifications are appropriate to the needs of the project and that sellers on 
the project perform according to their contracts. 

e Procurements are closed appropriately as the work of each contract is completed, verified by the seller and validated 
by the buyer. 


Understanding Contracts 


This section covers enterprise environmental factors for managing contracts, the project manager s role, types of contracts, 
and managing procurements using different types of contracts. 


The Contracting Environment 

For the exam, assume there is a centralized contracting environment unless otherwise stated. In a centralized contracting 
environment there is one procurement department. The procurement manager reports to the head of the procurement 
department and they may handle procurements on many projects. The project manager contacts the procurement manager 
or department when they need help or to ask questions and knows what authority the procurement manager has in 
each situation. 

In a decentralized contracting environment, there is no procurement department or procurement manager assigned. 
The project manager may be responsible not only for planning and managing procurement but also for conducting all work 
on procurements. There may be little standardization of procurement processes and contract language without a 
procurement department to regulate standards and improve knowledge in procurement management. 

Whether contracting is centralized or decentralized, the project manager is responsible for knowing their required 


level of involvement. Use the scenario described in the exam question to determine how involved the project manager 
should be. 


The Project Manager’s Role in Procurement 

You might ask yourself, “If there is a procurement manager, why would a project manager need to be involved in 
procurements?” This is an important question, and you must fully understand the answer before you take the exam. Here 
are a few tricks to help you. 
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TRICKS Remember that it is the project manager’s project. The project manager must be fully informed and apply their 
OF THE expertise for the organization to fully realize the project’s benefits. This trick is important for all processes and 
iA typically a large percentage of the questions on the exam focus on testing whether you know what you 
should do. 


Here is a quick summary. Do not memorize it; instead, make sure you understand it. 
+ Know the procurement process so you understand what will happen when and can make the necessary plans. 


e Make sure the contract includes all the scope of work and project management requirements, such as attendance 
at meetings, reports, actions, and communications deemed necessary to minimize problems and 
miscommunications with the seller(s). 


+ Incorporate allocation and mitigation of risks into the contract to decrease risk. 
+ Help tailor the contract to the unique needs of the project. 
+ Ensure sellers have the right information and are set up for success. 


+ Estimate the time and cost of each procurement, including what is required to complete the process. Include these 
estimates in the project schedule and budget. 


+ Be involved during contract negotiations to protect the relationship with the seller and promote the best interests 
of the project. 


+ Define quality requirements for and check the quality of goods and services from sellers. 


+ Remove impediments by making sure the procurement process goes as smoothly as possible, investigating any 
issues and taking corrective action. 


+ Understand what contract terms and conditions mean so you can read and understand contracts. 


+ Beyond the technical scope, ensure all the work in the contract is done, such as reporting legal deliverables, 
including the release of liens and ownership of materials. 


+ Make a formal contract change for anything that is not in the contract. 


+ Work with the procurement department to manage contract changes. 


TRICKS Project managers should be assigned on both the buyers’ and sellers’ sides before a contract is signed! Many 
(0J companies that sell their services make a huge but common mistake by not involving the project manager in 
IM the bidding and proposal process. Instead, only marketing and sales are involved until after the contract is 


signed. The project manager is then handed a project with a contract that may include unrealistic constraints. 
The project starts out in trouble. 

Involving the project manager early in the procurement process is so important that the exam will test you to see if 
you know when the project manager should be involved and why. The project manager and qualified team members are 
often uniquely capable of getting answers to many of the technical and project management questions that arise during 
bidding processes. If the sellers’ questions are answered incorrectly or incompletely, there may be an inadvertent change 
to a specification or the scope of the contract that was never intended by the buyer. 
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Contract Types 
Many different types of contracts can be used to acquire goods and services. Boilerplate contracts or agreements used 
within an organization are organizational process assets. The procurement manager selects the contract type for each 
procurement based on the following considerations: 

+ What is being purchased (a product or a service) 

+ The completeness of the statement of work 

+ The level of effort and expertise the buyer can devote to managing the seller 

+ Whether the buyer wants to offer the seller incentives 

+ The marketplace or economy 

+ Industry standards for the type of contract used 


Although the buyer initially proposes the contract type, the final contract type is subject to negotiation with the seller. 
The best contract type meets the needs of the procurement, results in reasonable seller risk, and provides the seller with 
the greatest incentive for efficient performance. 


The three broad categories of contracts are: 
+ Fixed-price (FP) * Time and material (T&M) * Cost-reimbursable (CR) 


Note: Be sure to read about sub-types of contracts within these three broad categories in the free 


L1 


article “Contract Types Subcategories,” on the RMC Resources web page (www.rmcls.com/ 
rmc-resources). 


Situational questions on the exam may require you to recognize that the project managers 
responsibilities and actions will vary depending on the type of contract being used. There may also be 
questions that require you to pick the most appropriate contract type based on a particular situation. 
Carefully think through this section! PNC RESOURCES 


Fixed-Price Contract (FP) 


A fixed-price contract should be used for acquiring goods, products, or services with well-defined requirements or 


specifications. In general, with a fixed-price contract, a clearly defined SOW along with competing bids mean you’re likely 
to get a fair and reasonable price. This is one of the most common contract types used, though it’s more likely to be used in 
construction than in something like information technology. 

If the costs are more than the agreed-upon amount, the seller must bear additional costs. Therefore, the buyer has the 
least cost risk in this type of contract because the scope is well-defined. Note, however, that when fixed-price contracts are 
entered into and the SOW is not sufficiently detailed, claims and disputes over what is in and out of the contract create 
higher risk of cost overruns or delay. 

The seller is most concerned with the procurement SOW in a fixed-price contract, since this will help them more 
accurately estimate time and cost for the work involved and determine a price that includes a fair and reasonable profit. The 
amount of profit is not disclosed to the buyer. 

For the exam, be aware that even though the buyer may prefer a fixed-price contract to control costs, it is not always 
the best choice, and in some cases, it may be inappropriate. Sellers in some industries may not have the detailed accounting 
records of past project activities required to accurately estimate future projects. Buyers may not have the expertise to 
prepare the clear and complete procurement SOW required for a fixed-price contract. 

Because many buyers are not knowledgeable about contracts, they often ask the seller to provide a fixed price even 
when the scope of work is not complete and accurate. Think about the following disadvantages if the procurement SOW is 
not adequate for the seller to make a reasonable estimate: 

* The seller is forced to accept a high level of risk. 

+ The seller needs to add significant reserves to their price to cover risk; therefore, the buyer pays more than they 

otherwise might have. 

+ The seller can more easily try to increase profits by cutting scope or claiming that work the buyer wants is outside the 
contract and thus requires a change order, and the buyer will not be able to state with certainty if it is within the scope 
of work or needs a change order. If the seller realizes they will not be able to make a profit they may try to take their 
best people off the project, cut out work that is specifically mentioned in the contract, cut out work that is not 


mentioned in the contract but is needed, decrease quality, or take other actions to save money. 
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Fixed-price (FP) In a FP contract, a fixed total price is set Example: Fixed-Price Contract 
for the project, all requirements have been clearly described, Contract = $1,100,000. 

and changes to scope should not occur. 

Purchase Order A purchase order is the simplest type of 

fixed-price contract. This type of contract is normally Seime reies Clicks 
unilateral (signed by one party) instead of bilateral (signed by Contract = 30 linear meters of wood at 
both parties). However, some buyers require the seller’s $9 per meter. 

signature on a purchase order before considering it official. In 

that case, the signature forms the acceptance needed for 

a contract. 


Note: A purchase order is usually used for simple commodity procurements. They become contracts when the buyer 
accepts the terms. The seller then performs or delivers according to those terms (for example, equipment or products). 


Time and Material (T&M) _ 


In this type of contract, the buyer pays on a per-hour or per-item basis. These contracts are frequently used for service 


efforts in which the level of effort cannot be defined when the contract is awarded. It has elements of a fixed-price contract 
(in the fixed price per hour) and a cost-reimbursable contract (in the material costs and the fact that the total cost is 
unknown). Compared to other types of contracts, time and material contracts typically have terms and conditions that are 
simpler to allow for quick negotiations so that work can begin sooner. 


If you were going to have to pay someone on a contract basis for every hour they worked, no matter how productive 
they were and no matter what they were doing, would you want to do this for a long period of time? Remember, the seller’s 
profit is built into the rate, so they have no incentive to get the work done quickly or efficiently. For this reason, a time and 
material contract is best used for work valued at small dollar amounts and lasting a short amount of time. Knowing when 
it’s best to use time and material contracts can help you get situational questions right on the exam. 


To make sure the costs do not become higher than Example: Time and Material Contract 


budgeted, the buyer may add a “Not to Exceed” clause to the 

contract and thus limit the total amount they are required to Contract = $100 per hour plus expenses 

or materials at cost. 
Or 


Contract = $100 per hour plus materials 


pay. With a time and material contract, the buyer has a 
medium amount of cost risk as compared to cost-reimbursable 


and fixed-price contracts. ó 
at $5 per linear meter of wood. 


Cost-reimbursable (CR) _ 


A cost-reimbursable contract is used when the exact scope of work is uncertain and, therefore, costs cannot be estimated 


accurately enough to effectively use a fixed-price contract. This type of contract provides for the buyer to pay the seller 
allowable incurred costs to the extent prescribed in the contract. Such contracts also typically include an additional fee or 
award amount added to the cost to allow for seller profit. 

A cost-reimbursable contract requires the seller to have an accounting system that can track costs by project. With a 
cost-reimbursable contract, the buyer has the most cost risk because the total costs are unknown. The seller provides an 
estimate to the buyer; the buyer can use the estimate for planning and cost management purposes, but it is not binding. 
What is binding is the buyer’s responsibility to compensate the seller for legitimate costs for work and materials as described 
in the contract. Research and development or information technology projects in which the scope is unknown are typical 
examples of cost-reimbursable contracts. 

Types of cost-reimbursable contracts include cost, cost plus fixed fee, cost plus incentive fee, cost 
plus award fee, cost plus fee, and cost plus percentage of costs. Here is one of the most common cost- 
reimbursable contracts. You can read about the others at the RMC Resources page at rmcls.com/ 


rmc-resources. 


RMC RESOURCES 
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Cost Contract A cost contract is one in which the seller Example: Cost Contract 


receives no fee (profit). It is appropriate for work performed > 
alc Contract = Cost for work and materials. 
by nonprofit organizations. : a 
There is no profit. The seller is reimbursed 


but does not make a profit. 


Indefinite Delivery, Indefinite Quantity (IDIQ) Contract 
This type of contact provides for an indefinite number of goods and services within a fixed time frame and within a certain 
cost range. For example, an architect may be hired for a period of one year to be available for any issues that arise as an office 


building is being built. The amount of service needed is undefined, but the contact length is set. Even if no services are 
needed, the seller will be paid the minimum amount stated in the contract. This contract type is used most often in 
engineering or information technology. 


The risk on this type of contract is equally split. If the Example: Indefinite Delivery Indefinite Quantity 


sellers goods or services are not needed in the allotted 
Contract = One-year contract for a minimum of 


timeframe, then the buyer accepts the risk (they have to pay 
$ 10,000 and a maximum of $ 18,000. 


out the minimum amount anyway). If the seller provides 
more goods and services than anticipated, they will accept 
the risk since their fee is capped. 


Risk and Contract Type 


Here is an overview of who takes on risk for the contract types. 
¢ Fixed-price contract The seller takes on most or all the risk. 
* Cost-based contract The buyer is assuming the risk in this type of contract. 


* Time and material contract Risk is shared between the seller and buyer. 


Advantages and Disadvantages of Each Contract Type 


Do you understand what you just read? Can you answer the following questions? 


* You do not have a finalized scope. Which contract type is best? 


+ You do not have a complete scope of work, but you have a fixed-price contract. What problems can you expect to 
run into? 


13.1 Exercise 
In your Exercise Notebook, write the advantages and disadvantages of each form of contract from the perspective 
of the buyer. The forms are: 


+ Fixed-price 
+ Time and Material 


+ Cost-reimbursable 
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Answer 


There can be more answers than listed here. Did you identify and understand these? 


Fixed Price Contract 


Advantages Disadvantages 


— This requires less work for the buyer to manage. — If the seller underprices the work, they may try to 
make up profits by charging more than is necessary 


on change orders. 
— Companies usually have experience with this type 


of contract. 


— The seller has a strong incentive to control costs. 


The seller may try to not complete some of the 


procurement statement of work if they begin to 
= The buyer knows the total price before the lose money. 


work begins. : : 
- This contract type requires more work for the buyer 


to write the procurement statement of work. 


- This can be more expensive than a cost reimbursable 
contract if the procurement statement of work is 
incomplete. The seller also needs to add to the price 
of this contract to account for the increased risk. 


Time and Material Contract 


Advantages Disadvantages 
- This type of contract can be created quickly because — There is profit for the seller in every hour or 
the statement of work may be less detailed. unit billed. 
- The contract duration is brief. — The seller has no incentive to control costs. 
- This is a good choice when you are contracting — This contract type is appropriate only for work 
people to augment your staff. involving a small level of effort. 


— This contract type requires a great deal of day-to-day 
oversight from the buyer. 


Cost-Reimburseable Contract 


Advantages Disadvantages 
— This contract type allows for a simpler procurement This contract type requires auditing the sell- 
statement of work. er 5 invoices. 
— This contract type usually requires less work to — This contract type requires more work for the buyer 
define the scope than a fixed-price contract. to manage. 


- This is generally less costly than a fixed-price contract - The seller has only a moderate incentive to 
because the seller does not have to add as much control costs. 


for risk. - The total price is unknown. 
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TRICKS A trick for the exam is to realize that buyers must select the appropriate type of contract for what they are 
OF THE azar 


TRADE Remembering the following general rules for situational questions involving contracts can help you get 


more questions right on the exam. 


e Contracts require formality. Correspondence, clarification, and notifications related to contracts should be formal 
written communication. If issues develop requiring arbitration, mediation, or litigation, formal written 
communications are more enforceable and supportable than are verbal communications. 


+ All product and project management requirements for procurement work should be specifically stated in 
the contract. 


+ Ifit is not in the contract a formal change order to the contract is needed for the work to be done. 

+ Ifit is in the contract it must be done or a formal contract change order to remove it is needed. 

+ Change requests to contracts must be submitted in writing. 

* Contracts are legally binding; the seller must perform as agreed in the contract or they are in breach of contract. 
* Contracts should help diminish project risk. 


* Most governments back contracts within their jurisdiction through a court system for dispute resolution. 


Agile Procurement and Contracts 
Procurement on agile projects is additionally challenging since scope is emerging. It may be difficult to 
sufficiently determine requirements up front for many contractors proposing for the work. The agile manifesto 


promotes “customer collaboration over contract negotiation” (see “Agile Methodologies” chapter). So agile 
contracting is built on relationships and ensuring that contracts are fair and equal. However, that doesn’t 
mean that a handshake is enough; the traditional fixed-price contract especially has its limits for an agile project. Here are 
a few example contracts tailored to agile: 


e Graduated fixed-price This contract has a fixed price based on completion by a certain date. If the work is completed 
before the target date, the seller is paid a higher fee, basically the fixed price plus a bonus. If the work is completed after 
the target date, the seller is paid at a fee lower than the fixed price. This incentivizes early delivery. 


+  Fixed-price work packages The contract can be paid in increments when work packages are delivered, rather than 
paid as one lump sum at the end of the contract. 
e Not-to-exceed time and material This is a time and materials contract that has a ceiling price for the work. It 


cannot go over this amount. 


+ Early termination This allows the buyer to cancel the contract early, for a cancellation fee, if it is discovered they no 
longer need the deliverable from the seller. 


On agile projects it is ideal to partner with a seller who also operates agile teams, because the contractor will 
understand the project better and be better able to deliver iteratively and incrementally if that is what is needed from them. 


They will at least understand the way the project will operate. In any case, project managers on agile projects should 
promote agile principles and practices to the extent possible with partners providing goods or services. When working 
with an agile contract, sellers may be involved in providing feedback on increment deliverables, prioritizing the backlog, 
and ranking the value of change requests on work. 

That said, many lessons from the Process Groups model for procurement can be used in agile environments. A 
contract professional, like a lawyer or contract officer within the organization should be involved in contracting, for 
example. In agile and predictive environments alike, organizations usually have strict policies and procedures related to 
contracts. In a hybrid environment, there can be a master contract for most of the contracted work and a supplement for 
any adaptive parts of the contract. This allows the flexibility needed for the adaptive work packages. 
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Additional Contracting Terms to Know 
Here are some contracting terms you might see on the exam. You can find more contracting terms 
that are good for a project manager to know on the RMC Resources page at rmcls.com/rmc-resources. 


° Sharing ratio Incentives are usually expressed as a ratio, such as 80/20. This sharing ratio 


describes how the cost savings or cost overrun will be shared; the first number represents the 
buyer portion and the second number represents the seller portion (buyer/seller). 


e Nondisclosure agreement For many procurements, there is a great need for confidentiality. RMC RESOURCES 
Such a written agreement between the buyer and prospective sellers identifies the information 
or documents they will control and hold confidential; it also details who in the organization will have access to the 
confidential information. With a nondisclosure agreement in place, the buyer can talk more openly about their needs 
without fear that the public or one of the buyer’s competitors will gain access to the information. 

e Standard contract Commonly created by the buyer, standard contracts are usually drafted—or at least reviewed— 
by lawyers and generally do not require additional review if used for the purpose for which they were intended. You 
should understand standard contracts, but also realize the project manager’s role in special provisions (described 
next). 

e Special provisions (special conditions) The project manager must understand standard terms and conditions but 
also determine when additions, changes, or deletions from the standard provisions are required. By facilitating 
necessary adjustments, the project manager can make sure the resulting contract addresses the needs of the project. 
The project manager (remember when taking the exam that you are the buyer’s project manager, unless a question 
states otherwise) meets with the procurement manager (if there is one) to discuss the needs of the project and to 
determine the final contract terms and conditions. 

Additions, changes, or deletions are sometimes called special provisions and can simply pertain to the type of 
project and project requirements, risk analysis and administrative, legal, or business needs. 

e Privity This simply means a contractual relationship. The following explains privity and shows how questions on 
this topic may be asked. 


Question: 
Think About It. Company A hires company B to do some work. Company B subcontracts to company C. The 


ray project manager for company A is at the job site and tells company C to stop work. Generally, does company C 
have to listen? 


Answer: 


No. Companies C and A have no contractual relationship. Company A needs to talk to company B, who needs to talk 
to company C. 


Can you see how this would be important to understand? Any directive that the project manager from company A 
may give to company C can cause liability for company A. For example, company A may have to pay delay claims to 
company B, plus the costs of delay to company C if company C stopped work at company As direction. 


Terms and Conditions 


There are many terms and conditions associated with procurements that may be considered. Let’s start out with a story to 
better understand some of these terms and conditions. 


Think About It. A project manager (the buyer) needed their team members trained on some equipment. They 
contacted a seller to do the work and then had their procurement department send the seller a contract. 
Meanwhile, the project manager arranged for team members to travel for the training. There were terms and 
conditions in the contract that said the buyer would have rights to create derivative works and copy handouts 
from class. The handouts were proprietary and already copyrighted. The seller could not and would not sign the 
contract. The class had to be cancelled when many people were already on planes to attend the training. 


Whose fault was this? The project manager should have made sure the procurement department understood what 
they were buying and also should have looked at the contract before it was sent to make sure its language was accurate. 
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Creating a contract requires the involvement of both the project manager and the procurement manager. Do you 


work with a procurement manager to review contracts on your projects? 


The following are categories of terms and conditions that can make up standard or special provisions. You can find 


more of these on the RMC Resources page at rmcls.com/rmc-resources. Be familiar with these concepts and what impacts 


they would have on a contract. The exam will often simply use these terms in sentences such as, “There was a force majeure,” 


and you’ll need to understand what that means (force of nature, like a flood or a fire). Conversely, you need to know that 


“There was a flood that made the seller unable to perform,” describes a force majeure. 


Assignment This refers to the circumstances under which one party can assign its rights or obligations under the 
contract to another. 


Breach/default This occurs when any obligation of the contract is not met. Watch out—a breach on the seller’s part 


cannot be fixed by a breach on the buyer s part. For example, failure to complete an item in the procurement statement 
of work (seller’s breach) cannot be handled by the buyer stopping all payments (buyer’s breach). 

A breach is an extremely serious event. The exam may present situations in which seemingly little things in the 
contract are not done. The response to a breach must always be to issue a letter formally notifying the other party of 
the breach. The project manager must understand the legal impheations of their actions. If they do not watch out for 
and send an official notice of breach, the project managers company could lose its right to claim breach later. 
Force majeure This refers to a situation that could be considered an “act of nature,” such as a fire or freak electrical 
storm, and it is an allowable excuse for either party not meeting contract requirements. If a force majeure occurs, it is 


considered to be neither party’s fault. It is usually resolved by the seller receiving an extension of time on the project. 
Who pays for the cost of the items destroyed in a fire or other force majeure? Usually the risk of loss is borne by the 
seller and is hopefully covered by insurance. (See also “Risk of loss” below.) 


Indemnification (liability) Who is Hable for personal injury, damage, or accidents? 


Intellectual property Who owns the intellectual property (for example: patents, trademarks, copyrights, processes, 
source code, or books) used in connection with or developed as part of the contract? This may include warranties of 
the right to use certain intellectual property in performance of the contract. 


Management requirements Examples of management requirements include attendance at meetings and approval 
of staff assigned to the project. 


Material breach This breach is so large that it may not be possible to complete the work under the contract. 


Retainage This is an amount of money, usually 5 percent or 10 percent, withheld from each payment. This money is 
paid when the final work is complete. It helps ensure completion. 


Risk of loss This allocates the risk between the parties to a contract in the event goods or services are lost or 
destroyed during the performance of a contract. 


Waivers These are statements saying that rights under the contract may not be waived or modified other than by 
express agreement of the parties. A project manager must realize that they can intentionally or unintentionally give up 
a right in the contract through conduct, inadvertent failure to enforce, or lack of oversight. Therefore, a project 
manager must understand and enforce all aspects of the contract, even if a procurement manager is involved in 
administering the contract. 


Incentives 
Sellers are usually focused on the profits, while buyers are focused on cost, performance, schedule, or a combination of 


these. Incentives are used to bring the seller’s objectives in line with the buyer’s and to motivate the seller towards efficiency. 


Think of an incentive as a bonus for the seller. The buyer will provide an additional fee if the seller meets some cost, 


performance, or schedule objectives. 


Can you see how incentives can change the focus of the seller’s work? If there is an incentive for cost savings, then the 


work is to complete the project and to look for cost savings. If the incentive is for some increased level of performance (for 


example, the system can handle more capacity than contracted for), then the work is to complete the project and to look 


for ways to increase performance. The seller gains profit from both activities. 
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Answer the following questions for each of the contract types (cost-reimbursable, time and material, and fixed- 
price). Write the answers in your Exercise Notebook. (This is the most challenging exercise in this chapter. The 


questions are meant to be very difficult in order to further test your knowledge.) 


Question 


Generally, what is being bought? (Product or service) 


medium, low, none) 


ga 


ow, none) 


9. How are costs billed to the buyer? 


. How might the costs to the buyer be stated in the contract? 


. How might the profit be stated in the contract? 


tk 
2 
3 
4. What is the cost risk to the buyer? (High, medium, low, none) 
5, 
6. What industry uses this contract type most frequently? 

7 


. How important is a detailed procurement statement of work? (High, medium, low, none) 


. How much negotiation is usually required to sign the contract after receipt of the sellers price? (High, 


What level of effort and expertise will the buyer need to devote to managing the seller? (High, medium, 


10. How much auditing of the sellers costs will the buyer need to do? (High, medium, low, none) 


Answer 


Compare the answers in the following table to your answers. 


1. 


Cost- Reimbursable 


Service (some products may be 
included) 


Costs are variable, but the fee/ 
profit is fixed (as a set amount or a 
percentage) 


Listed separately, and known to 
the buyer 


High; increases in costs are 
reimbursed by the buyer 


Low; the procurement statement 
of work only needs to describe 
the performance or functional 
requirements, since the seller 
provides the expertise on how to 
do the work; the buyer pays all 
costs, so there is less need to 
finalize the scope 


Time and Material 


Service 


Hourly rate or price per unit 


Included in the hourly rate, and 


may be unknown to the buyer 


Medium; although the costs are 
not fixed, they are known per 
unit, and this contract type is 
used for small purchases for a 


limited time 


Low; this type traditionally has 


very little scope, and may only 
describe skill sets required 


Fixed-Price 


Product 


As a set currency amount 
(e.g., $ 1 million) 


Included in the price, and 
unknown to the buyer 


Low; increases in costs are borne 
by the seller 


High; the procurement statement 
of work must be complete so the 
seller knows exactly what work 
needs to be done in order to come 
up with an accurate price to 
complete the work 
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Cost- Reimbursable Time and Material Fixed-Price 


IT, research and development, 


and knowledge work; when the M 
When hiring people for an hourly ; 
work has never been done before iG Complete scope of work is most 
E $ rate, you are usually hiring ; ? 
6. (as is often the case in these common in the construction 


services, such as legal, plumbing, 


industries), the seller cannot fix a ` industry 
price; therefore, this is the best SRP Ee 
form to use 
High; all estimated costs are 
7. looked at to calculate the fee to Low or none None 
be paid 
8. High Medium Low 
Actual costs as incurred; profit at Fixed price (which includes 
9 project completion, or Hourly or per unit rate (which profit) according to a payment 
` apportioned as allowed in the includes all costs and profit) schedule as work is completed 
contract and as allowed in the contract 


. Low; since the overall contract 
: : None; there may be an audit of ae 
High; all costs must be audited, costs are fixed, auditing usually 


work hours completed against 


j i those billed, but that will take i, 
of invoices i completed, not looking at 
little effort 


10. and there will be a large number focuses on making sure work is 


detailed costs and receipts 


Plan Procurements 


The Plan Procurement Management process answers these questions: “How 
will make-or-buy analysis be performed?” “What goods and services do we 
need to buy for this project?” “How will we purchase them?” “Who are poten- 
tial sellers to consider?” 
Planning involves putting together the bid documents that will be sent 
to prospective sellers describing the buyers need, how to respond, and the 
criteria the buyer will use to select a seller. Planning the procurement process 


includes the following: 
+ Performing make-or-buy analysis 


+ Creating a procurement management plan 


e Creating a procurement strategy for each procurement 

* Creating a procurement statement of work for each procurement 
+ Selecting the appropriate contract type for each procurement 

* Creating the bid documents 


+ Determining the source selection criteria 


What are the things you need to plan for procurements? When planning procurement management, it is important to 
consider business documents like the benefits management plan and the business case. You also need the project charter; 
components of the project management plan like the scope and schedule baselines and scope, quality, and resource 
planning documents; project documents; and any relevant enterprise environmental factors and organizational 


process assets. 
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The project charter provides any preapproved financial resources, while other project documents provide 


the following: 


e Milestone list + Resource requirements 

+ Project team assignments + Risk register 

+ Requirements documentation (including a + Stakeholder register 
requirements traceability matrix) + Procurements already in place 


Enterprise environmental factors for procurement include marketplace conditions, the services that are available to 
be purchased, and the existing culture and structures surrounding the organization’s approach to procurements. Relevant 
organizational process assets can include procurement procedures and documents, standard contract types used by the 
organization, statement of work templates, lessons learned from past procurements and projects. A preapproved (or 
prequalified) seller list and master service agreements, if they exist, are also useful. 

A preapproved seller list speeds up the process by helping ensure the sellers’ qualifications are well researched. The 
procurement documents are sent only to the preapproved sellers. Master service agreements are contracts between two 
parties including standard terms that will govern future transactions—a time-saving approach when a buyer frequently 
works with the same seller because overall terms of working together are already agreed to and signed by both buyer 


and seller. 


Methods for Planning Procurement Management 


Make-or-Buy Analysis 


During planning, you must decide whether the scope and work of the project will be completed within the organization or 
if some of it will be outsourced. It’s important to ask questions such as, “How are resources currently distributed?” and 
“What are the capabilities of our resources?” Make-or-buy analysis is done early in the planning phase of the project, and 


results in a make-or-buy decision. 


Logistics and Supply Chain Management 


An important consideration in make-or-buy analysis is the required lead time for materials and equipment to be purchased. 


Specialty items, custom products, and items ordered internationally will take more time, which must be built into the 


project schedule. 


Economic Measures 
Economic measures similar to those used in project selection and defined in the “Project Management Foundations” 


chapter may support make-or-buy decisions. Examples include payback period, ROI, IRR, discounted cash flow, and NPV. 
Expect to see questions on the exam that refer to make-or-buy analysis, or even questions that require you to calculate 
buy-or-lease situations, like the following question. 


i Think About It. You are trying to decide whether to lease or buy an item. The daily lease cost is $ 120. To purchase 
the item, the investment cost is $ 1,000; the daily maintenance cost is $20. How long will it take for the lease cost 


to equal the purchase cost? 
Answer: 
Let D equal the number of days when the purchase and lease costs are equal. 
$120D = $1,000 + $20D 
$120D-$20D = $1,000 
$100D = $1,000 
D=10 
The calculation says that the costs are the same after 10 days. Therefore, if you are planning to use the item for fewer 
than 10 days, you should lease. Otherwise it would be cheaper to buy the item. 
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Source Selection Analysis 
Project constraints are factors in seller (or source) selection. For example, is schedule the most important criteria or is cost 


the critical factor? You may want to review the project constraints in the “Project Management Foundations” chapter. 

Other source selection criteria are used and, as in project constraints, some are often weighed more heavily over 
others. If the buyer is purchasing a commodity, such as linear meters of wood, the source selection criteria may just be the 
lowest price. If the buyer is procuring construction services, the source selection criteria may be price plus experience. If 
the buyer is purchasing services, the source selection analysis criteria may include: 


+ Number of years in business + Technical expertise 
+ Financial stability * Quality of past performance 
+ Understanding of need + Ability to complete the work on time 


* Price or life cycle cost 


If the organization has a preferred seller list, or a master services agreement with an outside source, that information 
is also considered when analyzing source selection options. 


Artifacts of Plan Procurement 

The artifacts of planning for procurement include a procurement management plan. This plan documents or references 
governance for procurements. It provides guidelines and available tools for make-or-buy and source selection analyses, 
phase and transition management, and tailoring considerations. 


Conducting and controlling procurements are supported by planning, so these aspects are also covered in the plan. 
Rules and guidelines for procurement roles and responsibilities, bidder conferences, and negotiations are included. The 
control portion of the plan indicates how contract requirements will be managed, and it provides metrics and information 
on when and how measurements will be taken, guidelines for resolving disputes, the process for accepting deliverables, and 
the payments to be made. 


Make-or-buy decisions come out of the make-or-buy analysis, as does the procurement strategy. This strategy has 
three basic elements: 


* How goods or services will be delivered to the buyer (for example, will the procurement include subcontractors or an 
outside service provider) 


* Contract selection (for example, will the contract be fixed-price or cost plus; will it include incentives or award fees) 


+ How the procurement will be carried out for each phase. 


Other artifacts of planning procurement include the: 
+ Procurement statement of work (SOW) + Independent cost estimates 


+ Source selection criteria + Selected types of bid documents 


For independent cost estimates the buyer prepares an internal estimate, often using expert judgment to get a 
benchmark against which to validate the bids received from prospective sellers. The procurement SOW and bid documents 
were introduced earlier but let’s look at them in further detail. 


Procurement Statement of Work (SOW) 
The complete scope of a procurement is described in a procurement SOW. The project manager uses the same skills for the 


same outcomes that are expected from the work on the project's scope baseline, since each procurement represents a part 
of the overall project scope. 

Each SOW must be as clear, complete, and concise as possible, yet it must describe all the work and activities the 
seller is required to complete. This includes all meetings, reports, and communications. It must also detail the acceptance 
criteria and the process of gaining acceptance. The cost of adding activities later is typically more than the cost of adding 
them at the beginning of the procurement. Does this make you think about the work required to create a complete 
procurement SOW? 

Remember that the level of detail required for the SOW will influence the selection of the contract type and the 
creation of the bid documents. It may include drawings, specifications, and technical and descriptive wording. 
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What does “complete scope of procurement” mean? It depends on what you are buying. Here are some examples: 


. Expertise (e.g, software design or legal services) The procurement SOW includes functional and/or 
performance requirements, a timeline, evaluation criteria, and required meetings, reports, and communications. 


+ The construction of a building Specific requirements, outlining things such as the materials to be used, the process 
that must be followed, and work schedule. 


e Augmenting staff The project manager will direct these human resources so will need details of what the person 
will be assigned to create or achieve. 


Note: If the procurement is for services rather than products, the procurement SOW may be referred to as terms of 
reference (TOR). It includes the work the seller will perform, standards the seller is expected to achieve, and the data and 
services that will be provided to the buyer. 

The procurement statement of work may be revised during contract negotiation, but it should be finalized by the time 
the contract is signed as it is part of the contract. If the procurement SOW is not complete, the seller may frequently need 
to request clarification or ask for change orders, which can get expensive, and the project manager and/or the procurement 
manager may find themselves constantly dealing with questions about whether a specific piece of work is included in the 
original cost or time estimates. 


Think about change orders in the context of the procurement strategy and the project plan. In general, contract 
change orders cost money or cause delay. Bad procurement SOWs can result in overspending and delayed or failed projects. 


Bid Documents 
After the contract type is selected and the procurement statement of work has been created, the buyer can put together the 
bid document, which describes the buyer’s needs to sellers. The following are types of bid documents. 


+ Request for proposal (RFP) An RFP (sometimes called a request for tender) requests a detailed proposal that 
includes information on price, how the work will be accomplished, who will do it (along with resumes, in some 
cases), and company experience. 


* Invitation for bid (1FB) An IFB, sometimes called a request for bid (RFB), usually requests a total price to do all 
the work. Think of an IFB as a form of RFP where the work described in the procurement statement of work is 
detailed enough for bidders to determine a total price. 

* Request for quotation (RFQ) RFQs request a price quote per item, hour, meter, or other unit of measure. 


¢ Request for information (RFI) An RFI might be used before bid documents are created. Responses to the RFI 
help the buyer identify which companies are qualified to handle the procurement. Buyers can also use RFIs to collect 
information on what work is possible, for later inclusion in RFPs or IFBs. Remember that the purpose of an RFI is to 
get information, whereas the purpose of an RFP or RFQjs to buy something. 


To provide the seller with as clear a picture as possible of what needs to be done to win the work and what the work 
involves, bid documents may include the following information for sellers: 


e Background information about why the buyer wants the work done 

* Procedures for trying to win the work (such as whether there will be a bidder conference, when the responses are due, 
and how the winner will be selected) 

* Guidelines for preparing the response (such as maximum length and topics to address in the response) 


* The exact format the response should be in (such as which forms must be filled out and whether email submissions 
are allowed) 


+ Source selection criteria—the criteria the buyer will use to evaluate responses from the sellers (such as number of 
years in business, quality of the response, or price) 


* Pricing forms (forms to adequately describe the price to the buyer) 
* Procurement statement of work 


+ Proposed terms and conditions of the contract (legal and business) 
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a Think About It. Proposed contracts are included in the procurement documents. Do you know why? The 
oS terms and conditions of the contract represent work that needs to be done, and there are costs associated 

roa with that work, including warranties, ownership, indemnification, and insurance requirements. The seller 
must be aware of all the work that needs to be completed to adequately understand and price the project. 


Well-designed bid documents can have the following effects on a project: 
+ Easier comparison of sellers’ responses 

* More complete responses 

+ More accurate pricing 


* Decreased number of changes to the project 


Sellers may make suggestions for changes to the procurement documents, including the procurement SOW and the 
project management requirements included in the documents, before the contract is signed. When approved, these 
changes are issued by the buyer as addenda to the bid documents and will ultimately become part of the final contract. 


Noncompetitive Forms of Procurement 
Public organizations are generally required by law to follow certain practices regarding competitive procurements and to 
select a seller in a certain way. Although they might have internal policies to follow, private companies may bypass 
competitive procurement by using master service agreements or preferred seller lists, in which case they could simply issue 
a purchase order to obtain goods or services from an approved or preferred seller. 

If the project manager does not use a competitive process, they enter one of the following types of 
noncompetitive procurements: 


Sole source In this type of procurement, there is only one seller who can provide the goods or services. They may 
own a particular patent. 


Single source Here, the project manager contracts directly with the preferred seller without going through the full 
procurement process. The project manager may have worked with this company before, and, for various reasons, they 
do not want to look for another seller. In some cases, there may be a master service agreement in place between an 
organization and this seller: an established, ongoing contract. 


Other reasons for working with a company as a single source are: 

+ The project is under extreme schedule pressure. 

+ A seller has unique qualifications. 

+ Other mechanisms exist to ensure the seller’s prices are reasonable. 


+ The procurement is for a small amount of money. 


If the project manager is entering a noncompetitive procurement, they may save time by eliminating part of the 
process that comes before bidding but will still have to negotiate to finalize the contract. 


Once the make-or-buy analysis and procurement strategy are complete, the contract type has been selected, and a 
statement of work and bid documents are completed, the project manager is prepared to engage with prospective sellers. 
The bid documents and supporting documentation are sent, the project manager answers the sellers’ questions, possibly 


holds a bidder conference, and evaluates sellers’ responses. The project manager selects a seller using source selection 
criteria and then negotiates a contract. 
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Conduct Procurements 


Managing procurements includes carrying out the final strategy for finding a 
seller and negotiating and finalizing a contract with them. Information from 
the project management plan, including to-date baselines and other planning 
documentation, will assist in this process with prospective sellers and in mak- 
ing a final decision for each procurement. Because the process to finalize pro- 
curements is ongoing throughout the project, you and the team may be able 
to make use of lessons learned from prior procurements on the current proj- 
ect or previous projects, which can provide insight into the organizations’ ex- 
periences with sellers. This information can often streamline the process con- 
siderably. 


Methods for Conduct Procurements 
You may use tools and techniques such as advertising to find possible sellers 


or may send the bid documents to a select list of sellers preapproved by the 
organization (an organizational process asset). The organization may already have an existing agreement with a particular 
seller. In this case, you could work with that seller to negotiate terms to add new work to the contract. 


Note: The US government and many state and local agencies are required to advertise most of their procurements. 


Bidder Conference 
For a bidder conference the buyers side carefully controls communications with prospective sellers to ensure legal 
integrity, fairness, and consistency in the process. All prospective sellers’ questions are documented and sent to all 
prospective bidders—along with subsequent responses—to make sure everyone has the same information. 

Getting answers to questions can be important because many bid documents will include a provision saying that by 
submitting a bid or proposal, the seller warrants the bid covers all the work. The bidder conference is also an opportunity 
for the buyer to discover anything missing in the bid documents. 


A bidder conference can be key to making sure the pricing in the seller's response matches the work that needs to be 
done and is, therefore, the lowest price. Bidder conferences benefit both the buyer and seller. It is a good practice for the 
project manager to attend the bidder conference. The exam often asks what things the project manager must watch out for 
in a bidder conference. The answers include: 

* Collusion 

+ Sellers not asking questions in front of the competition 

+ Making sure all questions and answers are put in writing and issued to all potential sellers by the buyer as addenda to 

the bid documents (ensuring that all sellers are responding to the same procurement statement of work) 


Seller Proposal (or Price Quote or Bid) _ 


A proposal is usually the response to a request for proposal (RFP), a quote is usually the response to a request for quote 
(RFQ), and a bid is usually the response to an invitation for bid (IFB). The proposal (or price quote or bid) represents an 
official offer from the seller. RFP and RFQ,responses describe how the seller will meet the buyers request. A potential 
sellers response to an RFI provides information to help the buyer better define their procurement need. Responses to a 
request for information may trigger the buyer’s creation of an RFP or RFQ. Keep in mind that sellers may have many RFPs, 
RFQs, and IFBs sent to them. They need time to review them and determine which they are interested in responding to. 
To ensure the best sellers will be interested, the bid documents should be as complete and straightforward as possible. 

The buyers project manager should allow for this time—and the time required for the bidder conference and 
responses to that as well as the rest of the procurement process—in the project schedule. 


Proposal Evaluation 


A buyer proposal evaluation committee uses the source selection criteria to assess the ability and willingness to provide the 
requested products or services. This data analysis technique provides a basis to quantitatively evaluate proposals and 
minimize the influence of personal prejudices. 
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To select a seller the buyer may: 

+ Simply select a seller and ask them to sign a standard contract. 

+ Ask a seller to make a presentation, and then, if all goes well, move on to negotiations. 

* Narrow down (“short-list”) the list of sellers to a few. 

+ Ask the short-listed sellers to make presentations, and then ask the selected seller(s) to go on to negotiations. 
+ Negotiate with more than one seller. 


+ Use some combination of presentations and negotiations. 


The choice of methods depends on the importance of the procurement, the number of interested sellers, and the type 
of work to be performed. The sellers’ proposals are usually reviewed and compared by the evaluation committee using one 
or a combination of the formal, structured processes discussed next. 


Weighting System 

When the responses from sellers have been received, the buyers evaluation committee will analyze the responses and 
select a seller to award the contract to or to negotiate with. If the buyer is a public entity and the response is to an invitation 
to bid, the answer is simple. The work goes to the lowest responsive, responsible bidder. In the case of a proposal, the 
selection decision is more complicated. The buyer will apply the selection criteria chosen in planning. But which is more 
important? Price? Competence? Availability? Selection criteria are assigned values based on their relative importance to 
the procurement. For example, if price is more important, it will be given a higher rating and weight. The buyer’s evaluation 
committee then analyzes seller responses using the weighted source selection criteria. 

Example There are no calculations on the exam regarding weighting systems, but the following example should help you 
better understand the concept. 


Seller A 
AB C 
Rating for this category (1 Category score (column A 

Criteria Weight to 100) times B) 
Number of years in business 5 percent 50 25 
Understanding of need 25 percent 80 20 
Price or life cycle cost 10 percent 90 9 
Technical ability 25 percent 40 10 
ca to complete the work 20 percent 30 6 
Project management ability 15 percent 30 4.5 

Total score for this seller S2 


Past Performance History _ 
The buyer may consider both their history with the prospective sellers and feedback from other organizations who have 


done business with the sellers when determining which seller to award the procurement to. 


Independent Cost Estimates 
The buyer should compare the seller’s proposed cost with an estimate created in-house or with outside assistance during 
procurement planning efforts. This allows the buyer to discover significant differences between what the buyer and seller 


intend in the procurement statement of work. Responses that are significantly different from what is expected may indicate 
an issue with the sellers’ understanding of the procurement statement of work. 
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Presentations 

In many cases, some of the sellers will be asked to make presentations of their proposals. This is often a formal meeting of 
the buyers and seller’s teams. It provides the seller with an opportunity to present their proposal, team, and approach to 
completing the work. The buyer has an opportunity to see the team they may hire and to ask questions to assess the team’s 
competency. Presentations are used most often for procurements that have cost-reimbursable contracts, but they can be 
used whenever there is a lot to assess. 


Negotiations 
The exam typically has a question or two related to contract negotiations and the project manager’s involvement. You do 
not have to be an expert negotiator to pass the exam. But, as you have seen in other chapters of this book, the ability to 
negotiate is an important interpersonal skill for a project manager. Although the procurement manager or officer generally 
leads negotiations, the project manager is typically involved. Without the project managers’ involvement in negotiations, 
it is common for a contract to be signed that the project manager later discovers cannot be completed. 

It is important for everyone involved in negotiations to understand that the objectives of the negotiations are to: 

+ Obtain a fair and reasonable price 


* Develop a good relationship between the buyer and the seller 


A procurement should be a win-win situation. The buyer gets the work completed and the seller makes a reasonable 
profit. Projects can go bad without this win-win result of negotiation. Negotiation tactics are sometimes represented in 
situational questions on the exam. Be aware that buyers and sellers may use negotiation tactics such as delaying or 
withdrawal to get what they want. These are undesirable, of course, and you should have the skills to overcome these tactics. 

The main items to address while negotiating a contract can be different depending on what is being purchased. Scope, 
schedule, and cost are usually negotiated, in that order, although it always depends on project priorities. The clearer the 
scope definition, the easier it will be for the buyer and seller to come to a realistic agreement on the other items. Other 
items to be negotiated include risk, risk responsibilities, authority, applicable law (laws from a different state, country, or 
region should be reflected in the contract), project management process, payment schedule, and quality. 


When negotiations are complete, the contract is awarded to the selected seller. 


What Do You Need in Order to Have a Legal Contract? 
+ An offer 
+ Acceptance 
* Consideration (a transfer of something of value, but not necessarily money) 
+ Legal capacity (separate legal parties that are all legally competent) 


+ Legal purpose (there is not a legal, enforceable contract for the sale of illegal goods or services) 


A contract, offer, or acceptance may be verbal or written, though written is preferred since verbal agreements are 
difficult to enforce in a court of law. 


Artifacts and Results of Conduct Procurements 
The key result of the Conduct Procurements process are selected sellers and change requests. 


Selected Sellers 

After all the work of evaluating responses and negotiating with one or more prospective sellers is complete, a seller is 
chosen for each procurement. This means the buyer and seller have agreed and signed off on all terms and conditions of the 
contract, and they will move forward to create the product or service during the Control Procurements process. 


Change Requests 


The procurement management plan is likely to be iterated. Changes to any plan components, baselines, and other project 
artifacts are possible. Sometimes during project executing, problems that arise related to the procurement process (for 
example, a seller who isn’t performing) or to other areas of the project (such as risk, quality, schedule, or scope management) 
require reevaluation of the procurement management plan and make-or-buy decisions. Such planning changes need to be 
submitted through integrated change control, where they are evaluated against the entire project, and approved, rejected, 
or deferred. 
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It is important enough to restate that contracts may be finalized after other project plans are completed and approved. 


This could trigger the need for changes to any artifact of the overall project, potentially including the scope, schedule, or 
cost baselines or any other planning documents such as quality, resources, communications, or risk plan components. The 
preapproved seller list may also be updated based on work done in Conduct Procurements. 


Control Procurements 


Controlling a procurement once the contract is signed involves managing the 
legal relationship between the buyer and seller, ensuring that both parties per- 
form as required by the contract, and that each contract is closed when the 
contract work is completed. The Process Groups model calls this Control 
Procurements but note again that the ECO considers the entire procurement 
process be included within the Plan and Manage Procurement task. The work 
is the same regardless of what each resource calls it. The seller is focused on 
completing the work while the buyer is focused on measuring the perfor- 
mance of the seller and comparing actual performance to the contract, other 
procurement documents, and management plans. The exam tends to ask situ- 


ational questions focusing on what happens after the contract is signed, so 
this process is an important area on the exam. 


You should understand what problems and issues might affect the management of the project under each contract 


type. You will need to ensure that all work and legal requirements in the contract are accomplished, however small and 
seemingly unimportant. 


The project manager is continually measuring and assessing project progress as compared to the contract and 


procurement documentation and management plans. The tools and techniques described later in this section include 
many ways in which this is accomplished. When variances are identified, they are analyzed and may need to be managed 
using the integrated change control system. Approved changes will be integrated into the management plans or the 


contract. Contract changes are handled using the organizations’ contract change control system, which is an enterprise 
environmental factor. This system includes change procedures, forms, dispute resolution processes, and tracking systems, 
and is described in the contract. These procedures must be followed, and all changes should be made formally (in writing). 


niece] Sometimes exam questions ask how project control is different in a procurement, although it will often not be 
fomi asked in exactly these terms. These types of questions can be particularly difficult for those with little 
hi-y\e)=) procurement experience. Getting to a correct answer may include knowing that: 


The seller’s and buyer’s organizations have different cultures and procedures. 

The sellers objective is to generate revenue while the buyer’s objective is to complete the work. 

It is not as easy to see problems on the project when the contracted work is being done in a different location. 
There is a greater reliance on reports to determine if a problem exists. 


There is a greater reliance on the relationship between the buyers and seller’s project managers in terms of resolving 
issues not covered in the wording of the contract. 


Here are some other specific actions the project manager should be doing during this process: 


Interpret what is and what is not in the contract 

Interpret what the contract means 

Resolve disputes 

Make sure only authorized people are communicating with the seller 

Hold procurement performance review meetings with your team and the seller 
Understand the legal implications of actions taken 

Control quality according to what is required in the contract 


Authorize the seller’s work to start at the appropriate time, coordinating the seller’s work with the work of the project 
as a whole 


Manage interfaces among all the sellers on the project 
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The procurement management plan includes the actions the project manager and the team will take to oversee 
procurements, and the project manager may also review lessons learned to avoid the recurrence of issues experienced in 
the past. Approved change requests from integrated change control are also implemented in this process. 

The milestone list and schedule, scope, and cost baselines are used to confirm that the project is progressing as 
planned. Also: 


+ Requirements documentation This describes technical and other requirements the procurement is expected 
to meet. 


* Quality reports These indicate whether the work of the procurement is within the established quality metrics. 


+ Work performance data This comes from the Direct and Manage Project Work process (in “Integration”) and 
gives the project manager information on costs and the status of project activities, and is used to evaluate 
seller performance. 


In the contracts section we listed advantages and disadvantages of different contract types. The exam will require you 
to know that management efforts, issues, and potential trouble spots are different under each type of contract, meaning 
there will be different things the project manager needs to do depending on the type of contract. So with the following 
exercise, review these concepts and how they affect managing a procurement once the contract is signed. 


13.3 Exercise 

Hopefully, you have built a strong working relationship with the seller. But what if the seller has financial troubles, 
changes owners, or did not include pieces of the work in their estimate? In your Exercise Notebook, describe 
specific things you must watch out for and spend your time managing for these main types of contracts: fixed-price, 
time and material, and cost-reimbursable. 


Answer 
This is not a complete list! Think of what other actions may be taken. 
Fixed-Price Time and Material Cost-Reimbursable 
* The seller cutting scope. © Day-to-day direction to the seller. * Audit every invoice. 
+ The seller cutting quality. ® Get concrete deliverables. + Reestimate costs. 
* Overpriced change orders. © Ensure project length is * Monitor to confirm the seller’s 
* Scope misunderstandings. not extended. work is progressing efficiently. 
* Ensure costs are real, incurred ® Confirm the number of hours + Ensure all costs are applicable 
costs (not future or potential spent on work is reasonable. and chargeable to your project. 
costs)—unless there is an ® Watch for the need to switch to a + Watch for the seller adding 
agreement stating otherwise. different form of contract (e.g., resources that do not add value 
you determined a design SOW or perform real work. 
under a T&M contract and + Look for resources being shifted 
switch to a fixed-price contract from what was promised. 


for completion of the work). 
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Methods for Control Procurements 
Methods that can be used to manage procurements include performance reviews, inspections and audits, earned value 


analysis, and trend analysis. 


Performance reviews These include analyzing all available data to verify that the seller is performing as they should. 
Often, the seller is present to review the data and to discuss what the buyer can do to help advance the work. Together 
they determine if changes are needed to improve the buyer-seller relationship, the processes being used, and how the 
work is progressing compared to the plan. Any changes must be agreed upon in writing. 

Inspections and audits These may involve walkthroughs of the work site or deliverables reviews to verify 
compliance with the procurement statement of work. Do deliverables meet specifications? Variances or deviations 
may trigger change requests. An audit is performed by a team that includes representatives of both the buyer and the 
seller. The audit is to confirm that the sellers activities comply with approved procurement policies and processes. 
Variances are identified, formal adjustments are made accordingly, and lessons learned are captured. Note that in 
agreement with what we say in the “Quality of Deliverables and Products” chapter, inspections are related to 
deliverables while audits are related to processes, policies, and procedures. 

Earned value analysis Measurements identify scope, schedule, or cost variances from the performance 
measurement baseline. Variances are analyzed to determine their impact on the project. The results may be used to 
generate reports, forecast future performance, and predict actual completion dates and costs. Change requests may be 
made based on these results. 

Trend analysis This can determine whether performance is getting better or worse. It can be used to determine if 
preventive actions can prevent significant variances in the future and to develop forecast estimates and estimate 
at completion. 


Contract Interpretation and Managing Conflict 
Contract interpretation is never easy and frequently requires a lawyers’ assistance. However, the exam may describe a 
simple situation about a conflict over interpretation of a contract and then ask you to determine the correct answer. 


. 


Think About It. Conflict is an important topic that may be addressed in tricky procurement questions. In many 
cases the procurement manager (or contract administrator) is the only one with authority to change the contract. 
We have also said that the contract includes the procurement SOW. Think about the needed give and take 
between the project manager and procurement manager: 
The buyers project manager may want to initiate a change to the scope or sequence of work identified in the 
procurement SOW (an area seemingly under the project manager s control). 


They cannot do so without the procurement manager $ approval. This adds another layer to the project manager 's 
management activities that you may not have seen if you do not work with procurements. 


Can you see the potential for conflict between the procurement manager and the project manager? 


Think About It. Conflict can also occur between the buyer and the seller and may result in the seller submitting 
a claim against the buyer. A claim is an assertion that the buyer did something that has hurt the seller. The seller 
is now asking for compensation. 


Another way of looking at this is that a claim is a type of seller-initiated change request. 
Claims can get contentious. 
Imagine a seller that is not making as much profit as they had hoped issuing claims for every action taken by the buyer. 
Imagine the number of claims that can arise if the project manager is working with a fixed-price contract and an 
incomplete procurement statement of work. 
Claims are usually addressed through the contract change control system. The best way to settle them is through 
negotiation or the use of the dispute-resolution process specified in the contract. 


Many claims are not resolved until after the work is completed. 
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Contract interpretation is based on analyzing the intent of the parties, as reflected in the language of the 
contract, along with a few guidelines for interpreting that language. One such guideline is that the contract 
Ñ supersedes any memos, conversations, or discussions that may have occurred prior to the contract signing. 
Therefore, if a requirement is not in the contract, it does not have to be met, even if it was agreed upon prior to 


signing the contract. The following is an exercise on intent. 


13.4 Exercise 


Select which choice wins in a contract dispute. 


CHOICE A CHOICE B 

, Contract language Or A memo drafted by one of the parties describing proposed 
changes after the contract is signed 

2. Contract language Or A memo signed by both parties before the contract is signed 
that describes what was agreed to during negotiations 

3. Contract terms and conditions Or Procurement statement of work 

4. Common definition Or The intended meaning (without supplying a definition) 

5. Industry use of the term Or Common use of the term 

6. Special provisions Or General provisions 

7. Typed-over wording on the contract Or A handwritten comment on the contract that is also initialed 

8. Numbers Or = Words 

9. Detailed terms Or General terms 

Answer 


Check the answers below. Note: The answer to number 3 depends on the Order of Precedence Clause in the 
contract that describes which terms and conditions take precedence over the others in the event of a conflict 
between them. 


1A 4A 7.B 
2. A 5. A 8. B 
3. AorB 6. A 9. A 


Artifacts of Control Procurement 

The artifacts resulting from conducting procurements are change requests, procurement document updates, and 
closed procurements. 

Change requests Changes to a contract result when the buyer s’needs change while the work is underway, the impacts of 
the contract changes having been negotiated by the two parties. Contract changes may be requested throughout the 
procurement process and are handled as part of the project’s integrated change control efforts, along with all other project 
changes. Like other project changes, contract changes need to be analyzed for their impacts on all project constraints. 


Constructive changes You should be aware of the concept of constructive changes, which do not result from formal 
change requests. Rather, constructive changes occur when the buyer, through actions or inactions, limits the seller’s ability 
to perform the work according to the contract. This can include over-inspection or failure to hold up their end of the 
contract (e.g., failing to review documents or inspect deliverables on time). A simple direction to the seller to perform 
certain work that may seem minor can result in a constructive change that adds costs if that change is outside the scope of 
the contract. 
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Records management system Throughout the process of managing an active procurement, data on the contract and 
contract performance by both the buyer and the seller is gathered and analyzed. Because a contract is a formal, legal 
document, thorough records must be kept. Arecords management system maybe used to keep procurement documentation 
complete, organized, and accessible. Record keeping can be critical if procurement-related actions are questioned after the 
procurement is completed, such as in the case of unresolved claims or legal actions. Records may also be necessary to 
satisfy insurance requirements. 

For many projects, every email, every payment, and every written and verbal communication must be recorded and 
stored. On other projects, information about the weather and the number of people on the buyer’s property each day may 
be recorded. On large or complex projects, a records management system can be quite extensive and can require a person 
just to update it, including indexing, archiving, and information retrieval systems. 


Closed procurements Finally, procurements are closed as they are completed or terminated. All procurements must be 
closed out, no matter the circumstances under which they stop, are terminated, or are completed. Closure is a way to 
accumulate some added benefits, such as lessons learned. Closing a procurement consists of tying up all the loose ends, 
verifying that all work and deliverables are accepted, finalizing open claims, and financial closure (ensuring payment). The 
buyer formally notifies the seller the contract has been completed. There may be some obligations, such as warranties, that 
will continue after the procurement is closed. 


Many people who are new to procurement do not realize a contract can be terminated before the work is complete. 
The contract should have provisions for termination, which can be done for cause or for convenience. When too many 
changes are required the project manager should see if the existing contract no longer serves the purposes of defining all 
the work, roles, and responsibilities. It may be best to terminate the contract. The buyer may terminate a contract for cause 
if the seller breaches the contract (does not perform according to the contract), or simply terminate a contract for 
convenience if they no longer want the work done. 


A seller is rarely allowed to terminate a contract, but it could be appropriate on some projects. In any case, termination 


can result in extensive negotiations on what costs the buyer will pay. This is controlled by the language of the contract. In a 
termination for convenience, the seller is usually paid for work completed and work in process. If the contract is terminated 


for cause due to a default, the seller is generally paid for completed work but not for work in progress. The seller may also 
be subject to claims from the buyer for damages. Termination is a serious issue, and one that has lasting effects on the 
project. Termination negotiations can be drawn out long after the work has stopped—highlighting yet another reason why 
details of the project must be documented. 


Some people mistakenly think that the process of closing procurements is part of closing a project or phase. 
This comes up on the exam. Think of project closure as closing out a project or phase and procurement closure 


as completing only that particular part of scope that you have procured through a third party. Keep the 
following tricks in mind: 


* There may be many procurements in one project, so there can be many procurement closures, but closing a project 
or phase only happens at the end of the project or phase. 


+ Upon completion of the contract for each procurement, the project manager performs a process audit on the 
contract and the sellers performance before closing out the procurement. When the project as a whole is 
completed later, the project manager performs the final administrative and financial closure along with other 
processes required to close out the project. 


+ Read questions carefully. There may be questions that ask about the frequency of project closure or procurement 
closure. The way the questions are written will help you select the right answer. For projects that are managed in 


phases, closing the project or phase occurs at the end of each project phase as well as at the end of the project as a 
whole. In contrast, procurement closure is done at the completion of each contract. 


e To protect the legal interests of both parties, procurement closure requires detailed record keeping and must be 
done more formally than is generally required for project closure. 


Now let’s think about the real world. What do you think needs to be done at the end of the procurement in order to 
say the procurement is indeed finished? Wouldn’t it be substantially similar to what needs to be done when you close out 
a project in the Close Project or Phase process? Be careful on an exam question to be sure whether it is talking about 
closing a procurement or a project or phase. 
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13.5 Exercise 


In your Exercise Notebook, describe what work must be done during procurement closure. 


Answer 


As you read the answer, think about how similar closing procurements is to the Close Project or Phase process 
(although it is not the same process). Procurement closure includes all the following: 


e Product validation This involves the buyer validating and formally accepting (signing off on) the portion of 
project scope the seller is providing. It includes checking to see if all the work and documentation was 


completed correctly and satisfactorily. 


¢ Procurement negotiation The final settlement of all claims, invoices, and other issues may be handled 


through negotiations or a dispute resolution process established in the contract. 
¢ Financial closure Financial closure includes final payments and cost records. 


* Procurement process audit This is a review of the procurement process and capturing lessons learned. 
Normally this is done by the procurement manager and project manager, but companies that want to improve 


their processes may also involve the seller. 


* Updates to records This involves making sure all records of the procurement are complete and accessible. 
These records will become part of the procurement file (described later in this discussion). 


¢ Final contract performance reporting Think of this as creating a final report reflecting the success and 
effectiveness of the procurement and the seller. 


e Procurement file Finalizing the procurement file involves putting all emails, letters, conversation records, 
payment receipts, reports, and anything else related to the procurement into an organized file. This file will be 
stored for use as historical records. The project manager, with the help of the procurement manager, decides 
what documents need to be kept. 


Expect questions on the exam that describe a situation and require you to determine whether the procurement is 
closed. In gaining formal acceptance from (you) the buyer, the seller is also working to measure customer satisfaction. 


Putting It All Together 


That is the procurement process! Was a lot of this new to you? If you are inexperienced in working with procurements, re- 
read this chapter, and try to visualize how the different topics apply to a large project. Then visualize how it might work on 
other types of projects. This will help you understand the process better. 

Test your knowledge by completing the following exercise. Notice the word “actions” within this exercise. For the 
exam, you need to know what needs to be done during each step as well as what you have when you are done with a process 
(outputs or outcomes). This is an important exercise for ensuring that you can successfully answer procurement questions 
on the exam. 


13.6 Exercise 

Recreate the procurement management process by making a list in your Exercise Notebook of the key actions and 
of the artifacts resulting from Plan Procurement Management, Conduct Procurements, and Control Procurements. 
The answers to this exercise are listed after the next Trick of the Trade®. If you have missed many of the answers, do 
this exercise a second time after reviewing the material. 
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artifacts! 


If a question describes 
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some activity and that activity occurs 


Procurement 


Here is a trick for understanding the process without memorizing the whole thing—know only the 


after the procurement 


documents are created and before the contract is signed, then it must be taking place as part of the 


Conduct Procurements process. If it is taking place during the time after the contract is signed 


through when the work is substantially done, it must be occurring during the Control Procurements process. 


Answer 


The following actions and outputs are the ones you should give the most attention to when preparing for the exam. 


Key Actions For Each Procurement 


Plan Procurement Management Conduct Procurements 


. 


. 


Perform make-or-buy analysis. 


Create a procurement 
management plan. 

Create a procurement strategy. 
Create a procurement 
statement of work. 

Select the appropriate 
contract type. 

Create terms and conditions, 
including standard and 
special conditions. 

Create bid documents. 
Determine source 

selection criteria. 

Gather and analyze data on 
prospective sellers, the market, 
and market price. 

Estimate time and cost for 
contract and work. 
Make-or-buy decisions. 
Procurement 

management plan. 
Procurement statements 

of work. 


. 


Find potential sellers through 
advertising, a preapproved 
seller list, or other means. 


Send 

procurement documents. 
Hold a bidder conference. 
Answer sellers’ questions. 
Receive the seller responses. 
Compare the proposals to 
the source selection criteria 
using a weighting or 
screening system to pick/ 
shortlist the sellers. 
Receive presentations from 
seller(s). 

Compare to 

independent estimates. 
Hold negotiations. 


Use interpersonal and team 
skills, such as negotiation. 


Allocate risk to sellers 
when appropriate. 

Selected sellers. 

Signed contracts. 

Resource calendars. 

Change requests. 

Project management 

plan updates. 

Project documents updates. 
Recommendations and 
updates to the processes and 
procedures for organizational 


procurement practices. 


Organizational process 
assets updates. 


Control Procurements 


Understand the legal implications of 
your actions. 


Hold procurement performance reviews. 
Request changes. 

Administer claims. 

Manage interfaces among sellers. 

Monitor, analyze, and report on performance 
against the contract. 

Review cost submittals, and make payments. 
Perform inspections and audits. 

Maintain records of everything. 

Manage relationships. 

Accept verified deliverables. 

Perform procurement audits. 

Negotiate settlements. 

Create lessons learned. 


Complete final contract 
performance reporting. 


Validate the product. 

Issue formal acceptance. 

Update records. 

Create a procurement file. 
Perform financial closure. 
Substantial completion of contract 
requirements and deliverables. 
Work performance information. 
Change requests. 

Project management plan updates 


Project documents updates (including 
updates to procurement documents). 


Organizational process assets updates. 
Formal acceptance. 
Closed procurements. 


Lessons learned and records updates. 
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13.7 Exercise 


Here is another exercise to review what was discussed in this chapter. To pass the exam, you must understand the 
project managers role in procurements. After reading this chapter, describe the project manager s’ role. Write the 
answer in your Exercise Notebook. 


Answer 


As the project manager, you should: 


+ Know the procurement process so you integrate all procurements into your project. 
+ Understand what contract terms and conditions mean so you can read and understand contracts. 


+ Make sure the contract contains all the scope of work and all the project management requirements, such as 
attendance at meetings, reports, actions, and communications deemed necessary to minimize problems and 
miscommunications with the seller(s). 


+ Identify risks and incorporate mitigation and allocation of risks into the contracts to decrease project risk. 
+ Help tailor the contract to the unique needs of the project while it is being written. 

+ Include adequate time in the project schedule to complete the procurement process. 

+ Be involved during contract negotiations to protect the relationship with the seller. 


+ Protect the integrity of the project and the ability to get the work done by making sure the procurement 
process goes as smoothly as possible. 


+ Help make sure all the work in the contract is done—including reporting, inspections, and legal deliverables, 


such as the release of liens and ownership of materials—not just the technical scope. 
* Do not ask for something that is not in the contract without making a corresponding change to the contract. 


+ Work with the procurement manager to manage changes to the contract. 
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Introduction 


A student came into a class at RMC after having failed the exam. When talking with the student, Rita 
learned that he always worked with the same four people; his role was to simply tell them what to do. 
On many of his projects he was both a project manager and subject matter expert. 

For the exam you should assume your role is solely that of project manager, and you have a team 
who does the product development work. You are a leader on the project but you work collaboratively 
with other team members who manage how to do their own assigned work. 

Rita discovered that this student had only applied his own limited experience when he had 
studied for the exam. As a result, he failed to understand more broadly project management best 
practices. As a result, he was unable to tailor those practices to the wide variety of scenarios he 
encountered on the exam. 

As you read this and all chapters of this book, keep trying to increase your understanding of the 
practices presented so you can tailor them to any scenario. This will help you both in your career and 
on the exam. 


Definitions Related to Stakeholder Engagement 


The Cost of Change. 


The most critical reason for diligence in our 
stakeholder engagement efforts is that the closer 
we work with the customer on the product design 
and development, the fewer costly changes will 
come later. This means diligence in making sure 
we have identified all the stakeholders and begun 
to engage with them as early on the project as 
possible, and then work with them continually so 
there are no costly surprises down the road. The i construction 
goal is always to fulfill project requirements and 


opportunity for influence 


FIGURE 14.1 Cost of change and 


achieve customer satisfaction. À . 
influence on a design 


Why is it important to understand the 
importance of good, stable relationships with stakeholders? 
Early and consistent communication with stakeholders is critical because the cost of change rises 
over time, while the ability to influence a design falls. Changes made later in the project (when the 
product has already been gradually built) are harder to add than those made earlier on the project. 


This is illustrated in figure 14.1. 


Stakeholder _ 
A project stakeholder is one who is positively or negatively affected by or can positively or negatively 
affect the project or the product of the project. 

Planning, leading, and continuously evaluating stakeholder engagement will have an impact on 
your understanding of project management and your ability to pass the exam. Review this chapters 
Quicktest before you continue. Note which topics you are less familiar with and spend more time 
studying them. In this chapter, we discuss the stakeholder engagement process. We also cover methods 
and artifacts most often seen on the exam related to stakeholder engagement, from both plan-based 
and agile perspectives. 


Stakeholders FOURTEEN 


Think About It. Imagine you’re assigned as the project manager for a new project. Your department director 
© > gives you a charter and scope of work and tells you to get started. As the project manager, what do you do next? 
Often on the exam you will be asked what the project manager should do next. As you read the previous 
question, did you think that you should get started on the scope of work? Can the project manager accept a 
charter and scope of work without understanding the stakeholders and their requirements? 


Once the project manager has a signed charter (authorizing the project) and scope of work, the next steps for the 
project manager are to: 


* Identify all stakeholders + Develop strategies and tactics for 
+ Analyze their power, interest, and level of stakeholder engagement 
engagement ¢ Evaluate and incorporate stakeholder 


+ Elicit their requirements and expectations requirements as known into the project’s scope 

Engaging stakeholders and reassessing stakeholder engagement strategies and tactics should take place throughout 
the life of the project. The project manager and the team need to build and maintain relationships with stakeholders and 
make sure they are continuously involved in the project at the level necessary to make it a success. The project manager 
routinely looks for additional stakeholders that are new or have been missed, assesses whether the strategy is producing the 


needed results, and change strategies and tactics as necessary. 

Agile approaches include a member of the team as a key stakeholder, most often called the product 
owner. One of their main roles is to prioritize and maintain the backlog. It is also common to have frequent ‘alle 
demos for stakeholders of small portions of working product while it is still evolving. Predictive approaches Focus 


typically, in contrast, have stakeholders review more fully developed interim deliverables or work packages. 


Stakeholder Engagement Overview 


The Stakeholder Engagement process, regardless of the project’s approach and life cycle, requires a good understanding of 
the interpersonal and team skills that are covered in the People domain section of this book. Be sure to understand every- 
thing about the People domain before you read this chapter. People domain skills will help you to not only get those ques- 
tions right on the exam, but will also help you with the stakeholder engagement process skills covered in this chapter. 


The Examination Content Outline and Process Groups Model 
The following illustrates that Examination Content Outline (ECO) tasks 4,9, 10, and 13 in domain I, and task 4 in domain 
II can map directly to the stakeholder management process in the Process Groups model. Take time now with the ECO to 


think this through. 
Process Groups Model PMBOK® Guide 
Domain | Stakeholder Management Domain 2.1 
Task 4 Stakeholder 
Empower team members and stakeholders Identify Stakeholders — Initiating Domain 24 
Task 9 Plan Stakeholder Engagement — Planning Planning 
Collaborate with stakeholders 
Manage Stakeholder Engagement — Executing Domain 2.7 
Task 10 , ap Measurement 
Build shared understanding Monitor Stakeholder Engagement — Monitoring Domain 2.8 
& Controlling i 
Task 13 Uncertainty 
Mentor relevant stakeholders 
Domain II 
Task 4 
Engage stakeholders 
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Think About It. As you study this remember that stakeholder engagement doesn’t only relate to the ECO tasks listed 
in the previous table. Can you see how other People domain ECO tasks lend support to these tasks? You would not 
Qu Engage Stakeholders (domain II, task 4), for example, if you can’t apply all or most of the skills in 
g! main I (People). 
FEN Examples Manage Conflict (task 1) supports Build Shared Understanding (task 10). Engage & Support 
Virtual Teams (task 11) aids Empower Team Members and Stakeholders (task 4). 


Figure 14.2 shows the Stakeholder Engagement process from the Process Groups model perspective. Some activities 
related to this process fall within the communications area because communications is so closely related to 
stakeholder engagement. 


Key 
2 Continuous change control 
* =7 is consistent with all 


approaches 


Change prompts a process 
to be reiterated through 

v progressive elaboration 
or agile methods 


Remember, 
it's iterative 


M&C 
= Executing 


FIGURE 14.2 Stakeholder engagement process 


—> Changes that cause a 
return to Initiating are rare 


seeneencensee >> 


Using the Process Groups model as a starting point, you can see that the stakeholder engagement process consists of 
four sub-processes: Identify Stakeholders (which includes stakeholder analysis), Plan Stakeholder Engagement, Manage 
Stakeholder Engagement, and Monitor Stakeholder Engagement. 


The stakeholder engagement process can be summarized as follows: 


e Identify all stakeholders Do this as early as possible. The later stakeholders are discovered, the greater is the cost of 
the changes their new requirements involve. Determine requirements, expectations, interest, influence, level of 
authority, and values. 


>/ Requirements Obtain as many requirements as possible before work begins. The level of detail may differ 
at different stages depending on the project life cycle either because of progressive elaboration or 
development approach. Do you try to do this on your real-world projects? 


On a plan-based project the project manager tries to capture all project requirements as early 
in planning as possible. On an agile project only high-level requirements are captured up front and 


detailed requirements are gathered for each product feature as the iteration is planned. ae 
us 


V Expectations What are expectations? They are mental pictures of the future. They include what 
stakeholders think will happen to them, their department, and the company as a result of the project, and 
what they want from the project that has not been articulated or made into requirements. 
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Why not prevent as many issues as possible by walking stakeholders through what will occur and asking 


them what they expect? Evaluate these expectations, clarify some of them to foster a common understanding, 
and convert others to defined requirements. 


y Interest This means concern about the project. Determine the level of interest for each stakeholder. Are 
they likely to be engaged? How much of their attention and support do you need, and when do you need it? 


>/ Level of influence Each stakeholder will be able to impact a project negatively or positively to some degree. 
Identify and manage the level of influence for each stakeholder, even if informally. 


y Level of authority Each stakeholder’s level of authority (or ability to enforce decisions) will impact their 
effect on the work and outcome of the project. 


y Values Do project priorities align with the stakeholders’ standards that are also authorized within the 


project charter? Project managers should not plan or initiate work that the stakeholders do not support 
or value. 


e Plan Stakeholder Engagement Project management focuses on planning before doing. How will you engage 
stakeholders? How will you keep them involved in the project and include them in decision making? This engagement 
is tailored to the project and development approach. Communication is critical and is related to stakeholder 
engagement. Careful communication planning and implementation helps keep stakeholders at the appropriate level 
of engagement. 

y Communicate and engage Cultivate relationships with stakeholders and keep them well informed. Involve 
them in project presentations and information exchanges, including progress reports, the project 
management plan, and other artifact updates, as appropriate. 


y Manage expectations, influence, and engagement Work with stakeholders and manage relationships 
throughout the life of the project. 


e Monitor Stakeholder Engagement Throughout the project, determine if and where communications are breaking 


down, where engagement tactics and strategies are not working as needed, and adjust the approach as required to 
ensure that engagement is at the right level. 


TRICKS A key to your success as a project leader is how you handle stakeholder relationships. Stakeholder involvement 
OF THE must be appropriately influenced by the project manager. That involvement may range from minor to extensive 
HMA depending on the needs of the project, the team, the stakeholders, and the organization. 


Now we'll look more closely at each of these processes. 


Desired Outcomes from Successful Stakeholder Engagement 
Assume for the exam that stakeholder engagement is properly planned and managed unless information in an exam 


question indicates otherwise. This means that the following outcomes should be expected as a result of successful 
stakeholder engagement: 


. 


The project manager is able to establish and maintain a common understanding of the project, its objectives, 
constraints, and how they all are interacting to deliver the desired value the stakeholders will have from 
project deliverables. 

The project manager and team have good working relationships with the other project stakeholders, and the 
stakeholders are engaged at the desired level so as to help facilitate desired outcomes. 

The project manager knows what to do to adjust stakeholder engagement to desired levels as changes are needed 
because they have analyzed and planned for each stakeholder or stakeholder group’s needs. 

Stakeholders who do not support the project will not affect it or its outcomes adversely because the project manager 
communicates with them as needed to help them accept the project and its outcomes. 

+ The project manager achieves customer satisfaction with the key stakeholders who will be the beneficiaries of the 


product of the project. This is achieved through good working relationships, appropriate levels of communication 
and expectation management. 


FOURTEEN Stakeholders 


Stakeholder Identification (and Analysis) 


The first stakeholders are likely those who identify the problem or need. They 
may have been involved in developing business documents for the project. The 
business case and benefits management plan, created before project initiating, 
may include fists of stakeholders who will benefit from or be affected by the 
project. Other sources to identify stakeholders include contracts, agreements, 
and the project charter. 

Remember that any stakeholders who are missed will likely be found 
later, and their new requirements could cause costly changes and delays or loss 
of benefits and value. Project managers need to help create a project that 
considers all the interests, influences, and interdependencies of all stakeholders 
as early as possible. 

At the same time, this is hard to do perfectly. Why do you think that is? 


Changes within a project or organization 


may introduce new stakeholders 
A project manager and team may miss 
=e stakeholders initially 


————} Adaptive approaches include an evolving 
scope, which may mean an evolving 


i stakeholder list 
Even on predictive projects the stakeholder 


list evolves to some degree 


Throughout the project the project manager reassesses the stakeholder register and revisits the engagement strategy 
for existing stakeholders to determine whether new ones should be added and, if so, what that means for the project. 


TRICKS Many project managers fail to consider the broad range of potential stakeholders. 


Sponsor, team, product owner, senior management 


Subject matter experts, customers, product end users 


a Other departments or groups within the organization; 


functional or operational managers 


S Sellers, consultants, regulatory agencies, financial firms 


Government agencies 


If the project includes procurement, parties to contract(s) 


As agile practitioners know, this is a team process so be sure you are collaborating with the team on 
stakeholder identification and analysis. Also consult other stakeholders: subject matter experts, project 
managers in the organization who have worked on similar projects, and professional associations. Any = 
stakeholder may suggest other stakeholders to add to the list. 


Methods for Stakeholder Identification and Analysis 
Following are the methods for stakeholder identification and analysis that could appear on the exam. Remember this 
process includes a complete stakeholder analysis. 


Surveys, Interviews, and Focus Groups. 


These tools provide different ways to exchange information with team members and other stakeholders. They can be used 
to identify other potential stakeholders and provide input about management of different types of stakeholders or 


stakeholder groups. 
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Brainstorming 
Ibis method of shared idea generation can help identify stakeholders. 


Individual Stakeholder Analysis 


Every stakeholder has expectations and attitudes toward the project that need to be uncovered. How interested are they in 
the project, and what is at stake for them? Examples of stakes include the following: 


e Ownership The stakeholder may have to sell property for a proposed freeway expansion. 
° Knowledge The stakeholder may be the expert who designed a legacy inventory management system that is being 
upgraded or replaced. 


e Rights The stakeholder may be concerned that a new housing development will endanger the community by 
destroying the watershed. 


e Rights A government official may be responsible for ensuring that the safety practices on a construction site comply 
with state and federal laws. 


e Interest The community may be concerned that additional traffic will come into their residential neighborhood if a 
new commuter rail stop does not have adequate parking. 


e Contribution The resource manager may be concerned that resource team members assigned to the project will not 
be able to complete their normal operational work with the addition of project work. 


Document Analysis 
This technique assesses current and historical project documents, like lessons learned and other information from past 


projects (organizational process assets). The analysis can help the project manager identify stakeholders and their stakes in 
the project. 


Stakeholder Mapping 


This is a data representation method that maps stakeholder attributes into categories. Project managers use this method to 
analyze and plan how the project team will prioritize efforts to build relationships and engage stakeholders on the project. 
Stakeholder mapping examples include the power/interest grid, stakeholder cube, and salience model. Stakeholders 
can also be grouped by directions of influence (upward, downward, outward, and sideward). 
Power/Interest Grid This grid, shown in figure 14.3, is used to group stakeholders based on their level of power over the 
project and its outcomes relative to their interest in the project. It can inform the project manager about how to engage 
with a stakeholder based on these attributes. 
Variations of this tool emphasize other stakeholder attributes, such as power/influence or impact/influence. 
Stakeholder Cube This three-dimensional model is used to represent dimensions or aspects of a stakeholder group. An 
example is shown in figure 14.4. 
Salience Model This model is used to group stakeholders based on the appropriateness of their involvement (Legitimacy), 


their authority or ability to influence outcomes (Power), and their need for immediate attention (Urgency). An example 
of this model is shown in figure 14.5. 


i = 
š 
£ 


Keep Informed Maintain Interest poed 
Low Urgency 
Low High > 
eet FIGURE 14.4 Stakeholder cube FIGURE 14.5 Salience model 


FIGURE 14.3 Power/Interest grid 
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Personas 
A persona is a concise description of a real or imagined stakeholder model. Figure 14.6 is a sample persona Fm 
for the new library building project. Personas are created for agile projects to better imagine how each type of | A ) 
stakeholder will use the end product. A persona may be based on a real person or a combination of PaA 
characteristics from several types of product users. Focus 
When personas are used as a product design method, they should: 
+ Anchor team understanding in real types of people who will use the product 
* Provide focus for design and creation of specific and relevant product features 


+ Help make team members aware of design choice implications for product users 


Jemelia Job Seeker 


Description Values 
+ Looking for new job after completing + Free access to computer with easy apps 
bachelor’s degree in nursing + Free internet access 
+ Working as a home health aide + Easy instructions on the application 
* Does not have a computer for finding jobs process and how to access job boards 


+ Needs access to job resources at odd 
hours during time off 


FIGURE 14.6 Sample persona 


Look again at the card describing Jemelia Job Seeker as a persona. The goal is to make the best decisions regarding the 
creation of the product’s features and functions. By seeing through the eyes of a particular persona, it’s easier to imagine 
what the represented stakeholder group needs from the product. For example, the team can ask about a particular feature 
they are designing: What would Jemelia want from this feature? 


Artifacts of Stakeholder Identification and Analysis 
The Identify Stakeholders process results in a stakeholder register (and/or personas if it is an agile project), change requests, 
and updates to the project management plan and project documents such as the: 

+ Assumption log + Risk register 


+ Issue log + Personas (an agile method) 


Stakeholder Register 


Information about stakeholders is compiled in the stakeholder register, a key output of the Identify Stakeholders process. 
The stakeholder register (figure 14.7) may include each stakeholder’s detailed information. This register may include: 


+ Name & title Stakeholder Register 
Project Number 


e Supervisor 


Assemeneat [ats Rests 


e Project role € x x bina mon bena 
ame Te Egectmn Resgorsiires 0S) 0S) (0S) Camioane 


e Contact information 

* Major requirements and expectations 

+ Assessment information, impact, and influence 

+ Attitude (regarding the project) 

+ Stakeholder classification (grouped by similar attributes) 


S =i, Olen relevant information FIGURE 14.7 Sample stakeholder register 
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The stakeholder register is an important input to the Plan Stakeholder Engagement process as well as to several other 
stakeholder register will be 


planning processes, including Plan Communications Management. Remember that the 


updated throughout the project. 


Plan Stakeholder Engagement 


Stakeholders can be an asset or a problem, and this process is about establishing and 
documenting the optimal engagement level for each stakeholder (or stakeholder 
group). The project manager also needs to establish when each stakeholders’ en- 
gagement is needed, based on the stakeholder identification and analysis already 
done, and when engagement levels and strategies should be reassessed for each 
stakeholder or group. 


On the exam, assume there is a plan in place about how the project 
manager, the team, and the project outcomes will impact stakeholders, 
interact with them, manage their expectations, involve them in 


decision-making, and keep them satisfied to ensure they are an asset. 


Knowing stakeholders well leads to better confidence and success for the 
project manager and the team. Requirements will be delivered and, because all 
expectations have been managed (even those that do not rise to the level of being a 
requirement), customer satisfaction will be achieved. 


As a project manager, the closer you are to stakeholders, the more comfortable they will be to come to you with their 
concerns, and the easier it will be for you to pick up on nonverbal cues that can tell you something might be wrong. This 


can be an early warning system for problems on your project. But you may wonder how you build positive and powerful 
relationships with your stakeholders. The same way you have built them with your friends and family: By spending time 


getting to know them and allowing them to know you. Draw on your experience with your family, friends, coworkers, and 
others. You’ll be better able to determine your stakeholders’ needs, concerns, values, and expectations. 


Make sure you are comfortable with these concepts in a project management context so they will be easy to bring to 


mind when reading exam questions. Take a few minutes to think about the characteristics of a good relationship. You may 


think of different or additional qualities, but here are a few you want to nurture in your relationships: 


e Trust + Respect 

+ Honesty e Concern 

+ Interest + Empathy 

e Sincerity * Good communication 


As you plan stakeholder engagement, you will need to: 

+ Use your experience on other projects 

e Get the details of what has already been planned or documented including: 
V Information from the stakeholder register 


V Resource and communications management information and plans 


>/ Relevant information from past, similar projects (historical records) 


* Consider how much and what type of engagement you need from different stakeholders during each project stage. 


Talk to them so they can contribute ideas that will help them stay engaged as needed. 


Example You require some stakeholders to be more involved during planning, while others will have a more 


prominent role during executing. 


+ Meet with your key stakeholders as soon as possible to initiate these important relationships. 
* Think about each stakeholder’s role, the environment in which they operate, and the specific needs of your project. 
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* Think about each stakeholder s attitude and interest in the project. 

+ Determine which stakeholders will require most of your time and effort. 

+ For stakeholders you don’t know very well, talk to another project manager or team member who has worked with 
them in the past. 

e Make sure stakeholders understand how important it is for the project to meet their needs, and encourage them to 
communicate frequently as the planning and project work proceed. 

* Meet with professional organizations, consultants, and subject matter experts to hear insights on working with various 
stakeholders and stakeholder groups. 


+ If there are any procurements in place, coordinate with the procurement department to plan efforts related to parties 
of the contract. 


e Plan review meetings to get feedback on progress. 


* Decide how adjustments to engagement levels will be achieved, based on current knowledge of the project and 
its stakeholders. 


* Plan for how and with what frequency you will identify and analyze variances between current and desired levels of 
engagement. Work with the team to identify ways to achieve the right engagement levels. 


TRICKS Not every stakeholder will be as engaged in the project as you need, and some might be more engaged than 


(0j A You would wish. Stakeholder engagement can range from unaware of or resistant to the project to neutral to 
supportive or even interested in taking a leading role on the project. 


14.1 Exercise 

Let’s consider an example. Imagine you are managing a project to replace the online employee application process 
for your company. Your sponsor wants to streamline the process and encourage candidates with advanced technical 
experience to apply for jobs. Here is a preliminary stakeholder list. 


Key Stakeholders 
Stakeholders (With whom you'll spend the most time) 
Sponsor: HR director Sponsor 
Potential candidates (possibly millions!) Hiring managers 


Hiring managers within the company 


Is anyone missing from the key stakeholder list? Write it down before reading on. 


Answer 

You will want to receive frequent feedback from key stakeholders about how the design meets their requirements 
and expectations. If you haven’t done so already, add to that list a few newly hired employees who could help the 
team understand problems with the existing application process, as well as website administrators and human 
resource administrators (and there maybe more!). 
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Methods for Stakeholder Engagement Planning 
As the project manager you will need to choose tools to plan stakeholder engagement that are appropriate for the project. 
The following is not an exhaustive list but is a good representation of what is needed. 


Stakeholder Engagement Assessment Chart 


This is a data representation tool (and an artifact) used to compare stakeholders’ current and desired level of engagement. 


The stakeholder engagement plan documents what action will be taken to achieve optimal engagement. This chart (figure 
14.8) is used for establishing strategies and tactics for ongoing stakeholder engagement. It is also used in the 
monitoring process. 


Highly en 
ighly engaged E Current engagement level 


E Optimal engagement level 


Moderately engaged 


No engagement 


Stakeholder 1 Stakeholder 2 Stakeholder 3 


FIGURE 14.8 Stakeholder engagement assessment chart 


Assumptions and Constraints 
Analysis evaluating assumptions about stakeholders’ attitudes toward the project enables the team to determine actions 


needed to adjust levels of engagement to benefit the project. Analysis of project constraints can provide insight into 
determining strategies to adjust stakeholders’ levels of engagement. 


Root Cause Analysis 


This is a way for the project manager and team to analyze the cause of the current level of stakeholder support and 
engagement. Doing so will help them determine how best to facilitate a change to bring the stakeholders’ engagement to 
the desired level. 


Project Elevator Statement (Product Vision Statement) _ 
These are short descriptions of the project goals and benefits that allow the project manager to explain the 
project in the span of an elevator ride. Stakeholders could be involved in creating the project elevator statement p- 


(also known as “elevator pitch”) to help everyone understand the project and convey it to others. Following Agile 
Focus 


is a popular format for elevator statements: 


For: Target customers 
EXAMPLE: 

Who: Need (opportunity or problem) 

7 . For people who want to stream video 
The: Proove Service nan content the Viking Ultimate service is_a 
Is a: Product category streaming service that is fester, cheaper, and 
That: Key benefits/reason to buy better, unlike ABC services we have no 
Unlike: Primary competitive alternative(s) Isaygiiy eons: 
We: Primary differentiation 


TRICKS On the exam, “elevator statement” or “elevator pitch” will likely signal the question is about an agile (or agile 
OF THE portion of a hybrid) project, influencing your answer. However, look for other clues to ensure this is a correct 
Hii assumption. The “elevator statement” or “elevator pitch” is a common business concept that dates back to 
long before agile and is used in many contexts, including traditional project management. On agile projects 
this may also be called a Product Vision Statement. 
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14.2 Exercise 


If you’ve never planned stakeholder engagement, it can be difficult to imagine how you would go about doing this 
on an individual stakeholder (or group) level. Think about the various stakeholders involved on a project. The 
following table describes a few stakeholder descriptions based on collections of attributes that can be identified 
and analyzed. 


In your Exercise Notebook, write down how you would plan to manage the involvement of each of these 
stakeholders based on the given descriptions. On your projects, you will want to think about this in planning so 
that as you are working with the processes of managing and monitoring stakeholder engagement you will know 
what to do. 


Stakeholder Description 
1. High interest, low influence, shows high expertise on high-risk areas 
Low interest, the source of major requirements (high influence), not very responsive to communications 
High interest, high influence, doesn’t support the project 
High interest, high influence, supports the project 


Moderate interest, high influence because they have identified many potential risks, supports the project 


Aw Rwy 


Moderate interest, nervous about completing assigned activities 


Answer 


Listed here are suggestions for how you might plan to manage stakeholder engagement based on the descriptions 
in the previous table. These are general descriptions and answers, but will help you better understand the work 
needed for stakeholder engagement planning and management depending on different stakeholder attributes. 


Options for planned engagement strategies and tactics based on stakeholder descriptions. 
1. Invite the stakeholder to participate in analyzing the risks on the project. 
2. They may be overscheduled. Identify ways to elicit requirements as efficiently as possible. 


a. Determine why responsiveness is low. Ask them about how they would like to be involved with the 
project, and with what communication methods (email, phone calls, meetings, etc.). 


b. Make sure requirements are clearly captured and approved by the stakeholder as accurate. 
c. Send reports to ensure they have the information they need even if you do not get feedback. 
3. Use emotional intelligence. Ask the stakeholder what is important to them relative to the project. Ask 


them how you can gain their support for the project. 


4. Involve them in team meetings, report project performance to them, and, as appropriate, include 
information as the stakeholder requests. 


5. Plan to meet with them periodically throughout the project to potentially identify other risks. Keep them 
informed about the effectiveness of risk efforts; involve them in risk reviews and audits. 


6. Plan to find and forward relevant literature to help them, and arrange for training as necessary. 
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Artifacts of Stakeholder Engagement Planning 
The main artifact of Plan Stakeholder Engagement is a stakeholder engagement plan that aids the project manager in the 
planning, managing, and monitoring of stakeholder engagement. 


The Stakeholder Engagement Plan includes: 
+ Existing and desired engagement levels for all stakeholders, including plans to achieve desired levels. 
* Details about ways in which stakeholders will be involved in the project 


e Guidelines and metrics for monitoring and evaluating how well the plan is meeting the needs of stakeholders and 
the project. 


Often, less formal stakeholder engagement plans are needed in adaptive environments. 


Example Scrum (a specific agile approach) builds frequent stakeholder interactions into the build-and- 
review cycle. A sprint (iteration) is for building a product increment. Following the sprint, a sprint review 
involves demonstrating the newly built product increment to the customer. Then, a sprint retrospective Agile 
includes time set aside for the team to review what went right, what went wrong, and what they could do roe 
differently. You can see that frequent stakeholder engagement is built into this approach. 


We use Scrum as an example here but other types of agile teams work similarly to build and review product increments 
and to then review their processes and ways of working. With an agile approach the product owner participates in all parts 
of the build-and-review cycle, representing value delivery for the customer. Since a predictive environment has longer time 
horizons between when deliverables are completed to when they are shown to the customer, a more formal stakeholder 
management plan is often used. 


Stakeholder and communications management plans may have similar information about stakeholder and 
communication requirements. Each plan has a different focus and portions of them are created together. The 
stakeholder engagement plan explains the importance of which stakeholders need to receive which 
information. The communications management plan contains details about communications technology and 
methods—for example to generally state when using email is best versus making a phone call. 


TRICKS Be careful about what is documented in a stakeholder register or other related documentation, and with 
GF THE whom you share it. Consider sensitive information learned about attitudes and personalities, or about 

j¥V iA challenges. It could be damaging for someone to find this type of information. A good leader is encouraging 

and supportive of everyone, even those who are resistant to supporting the project or spending time working 

with you. As you discover a stakeholder-related challenge, you may decide not to share it (or not to document it). 


aS 


Manage Stakeholder Engagement 


At this point, the project manager has identified and analyzed the stake- 
holders and stakeholder groups on the project, and planned for optimal 
engagement with them. In this process the project manager carries out that 
plan based on what is known. Throughout the project the project manager 
will communicate and work with stakeholders to meet their project re- 
quirements and manage their expectations—whether or not all their ex- 
pectations are actual product or project requirements. Although it is asso- 
ciated with the executing process group in the Process Groups model, 
managing stakeholder engagement is inherent in everything the project 
manager does on a project. 

As the project manager, are you concerned you don’t have time to 
keep up with communications, or encourage stakeholder support while 
collecting their input and concerns? These efforts actually help you be 
more efficient by reducing the time spent dealing with problems. When 
taking the exam assume that these good stakeholder management 
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practices are followed—unless the question or answer choices indicate otherwise. This work also requires good 
interpersonal and team skills such as political and cultural awareness, negotiation, and conflict management. 

During executing, the project manager: 

+ Implements the stakeholder engagement plan 

e Consults the communications management plan and implements strategies and tactics from there 

+ Reviews other management plans and project artifacts, such as the: 


V Stakeholder register -/ Change log 
V Issue log y Risk register 


Think About it. Hopefully you are thinking holistically as you read this book. For example, the previous list 

- had, “Consults the communications management plan and implements strategies and tactics from there.” If you 
a were thinking holistically then you would have continued the thought with “and change these strategies and 
tactics as needed.” If you did this, then you are on the right track to not only integrating all your technical project 
management skills, but to also tailoring your project management strategies and tactics to the current situation 

on the current project. This is the type of holistic thinking you want to take to everything you read in this book 


and all your exam preparation. 


The things you have seen in the list so far relate to technical project management skills. What about those People 
domain skills covered earlier in this book and in the Stakeholder Engagement Overview section of this chapter? They are 
worth repeating here and include but are not limited to: 
+ Consult the team when working to address issues 
+ Collaborate with stakeholders (including the team) to build (and maintain) trust, and to influence them to help 
accomplish project objectives (domain I task 9) 

+ Manage stakeholder expectations to balance these with project and product requirements and objectives (domain I 
task 9) 

+ Continue to build and ensure a common understanding, avoiding as many misunderstandings as possible (domain I 
task 10) 


Think About It. What other ECO task may relate to this process? Quickly scan the People domain of the ECO, 
and also think about how its People (domain I) tasks are related not just to this “Manage” process of the Process 
Groups model, but also the “Monitor” process we discuss in the next section of this book. The same People skills 
are used for both Manage and Monitor, and in fact for all Stakeholder Engagement (and other project manage- 
ment process) needs. 
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Methods for Managing Stakeholder Engagement 


We will not provide explanations here for each of the following methods for Manage Stakeholder Engagement because 
they have already been or will be discussed in this book in many different contexts. Take a moment to review the most 
common methods for Manage Stakeholder Engagement, and for the overall Engage Stakeholders processes. Do understand 


that because something appears in one column does not mean it is not applicable to any environment along the spectrum 


from predictive-to-adaptive and hybrids in between. 


Common Methods Associated with Predictive Environments Methods Associated with Adaptive Environments 


- Bidder conferences (procurement) 

- Change control board (integration) 

- Kickoff (integration) 

— Lessons learned (integration) 

- Closeout (integration; closing process group) 
— Project review 

— Risk review 

— Status 

— Steering committee 


- Project review (e.g., review of project results against baselines, 
also known as EVM or earned value measurement or earned 
value management) 


Artifacts of Manage Stakeholder Engagement 


Managing stakeholder engagement may bring changes to: 
* Stakeholder engagement plan 
+ Communications management plan 
* Other project artifact updates, such as the: 
y Change log 


V Stakeholder register 


Taking another look at the Methods Associated with Adaptive Environments column in the previous 
table, you would probably agree that artifacts from the types of meetings on agile projects (also called 
ceremonies) are sometimes intangible, like good relationships with stakeholders (a desired outcome of 
stakeholder engagement), and sometimes very tangible. Consider the following: 


Backlog refinement 

Using timeboxes (e.g., a 2-week iteration) 
Daily standup 

Release planning 

Iteration planning 

Iteration review 

Retrospective 


Project review (e.gs., review/refinement of velocity; 
flexible scope for change control) 


y Issue log 
y Lessons learned 
(A) 


= 
Agile 
Focus 


e Continuous improvement in stakeholder relationships This happens as a natural result of the rituals through 


which agile practitioners work. Reviewing the list, just think about how many opportunities each team member and 


stakeholder has to promote a common understanding. 


e Gulf of execution and evaluation This gulf is bridged through short iterations (using timeboxes) followed by 
iteration reviews. The customer gets to see small product increments and discuss them with the team, and in this way 


clarify their own understanding of their requirements of the product and how to convey those requirements to the 


team. The team in turn gets better at understanding and building what the customer needs. 


¢ Better product integration By planning and building iteratively and incrementally, each product increment can be 
right and “done” before it is integrated with the larger product being built. This should result in fewer problems with 
continuous integration of product increments and with the evolving, working product. 


* Can you think of other artifacts of these practices? 
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14.3 Exercise 

The exam will present scenarios for which you will have to choose the best answer. You can practice gathering 
information from these scenarios by doing this exercise. Read the following scenarios and write down your own 
analysis. What evidence do you see of where you are in the project management process or about what has already 
taken place before this scenario? Quick observation of what is taking place as you read a given scenario will help 
you answer exam questions. 


ils 


Scenario. A stakeholder is dissatisfied because their request was not included in the product scope. All other 
stakeholders agreed on the scope but the project manager anticipates this person will continue pressing to add 
their request. The project manager meets with the stakeholder to talk about why this request was not included 
and to suggest they build a business case to include it in a new project. 


Scenario. A stakeholder expressed concern about how much the project would impact their department’s 
work. The project manager tells them, “I have your concern in mind. There is little probability we could 
implement this without impacting your department but here is an assessment of the expected impacts, when 
impacts are likely to occur, and how the team may mitigate the effects. Would you like to discuss it after reading 
it?” 


Answer 
Here are some example analyses. Your analyses may not match these exactly, so be sure that you understand and are 
confident about your and these analyses of the given scenarios. 


L 


Analysis. From the words “was not included,” we see the Create Scope Statement process (in the Planning 
column of Rita’s Process Chart) is already complete. The project manager is anticipating “this person will 
continue...” so the project managers ‘strategy is about the future. A business case for another project is the 
stakeholder’s best option. The project could be in planning or executing, but the project manager has monitored 
stakeholder engagement to make this observation and is looking ahead for good expectation management. 


Analysis. The project manager has anticipated the stakeholder’ concerns and has planned for mitigation 
while the project is ongoing. This is good stakeholder engagement practice, which is also taking risk into 
account. When reading questions, keep project integration in mind. 


Monitor Stakeholder Engagement 


What we learn from managing and maintaining stakeholder relationships helps 
ensure the planned strategies and tactics are working as intended. Monitoring 
stakeholder engagement helps the project manager know when adjustments are 


needed 


quirements, the project manager needs to do the following: 


* Update the stakeholder register to: 


and when to make those adjustments. Along with fulfilling project re- 


Understand stakeholder perceptions of project progress 
Review and evaluate stakeholder engagement during the project to 
enhance stakeholder collaboration 


Adjust strategies and tactics to ensure continuous stakeholder satisfaction 


V Add stakeholders as appropriate 
V Adjust stakeholders’ noted involvement as necessary 


y Note when a stakeholder’s involvement is no longer necessary 
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Artifacts that feed into (or are inputs) to this process include the stakeholder engagement plan, the communications 
management plan, the resource management plan, the issue log, and the lessons learned and risk registers. Does this sound 
familiar from the previous process of Manage Stakeholder Engagement? Outputs from one process are often inputs to the 
next process. 


Methods for Monitoring Stakeholder Engagement 

Monitoring stakeholder engagement requires the project manager to collect and analyze data. When engagement strategies 
and tactics are not working they need to analyze why those strategies are not returning the intended results. The stakeholder 
engagement plan should specify how this analysis and evaluation will be accomplished, who should be involved, how the 
results should be documented and presented, and how changes will be handled. If a large change will affect the performance 
measurement baseline in any way then a more formal change request is needed; but the project manager can and often 
does make many small changes to stakeholder engagement strategies and tactics without formal change requests. 


Utilizing Data 
Look at figure 14.9. When using data to compare actual to planned engagement levels, there may be variances that need a 
response to bring stakeholder engagement to the desired level. 


œ Project performance © Planned engagement. e No. Do nothing different. 
measurements. e Actual current engagement. Yes. Use preventive and 
œ Engagement levels of corrective actions. 
specific stakeholders. Yes. Problematic? May need 
a formal change request. 


FIGURE 14.9 Utilizing work performance data to compare actual to planned engagement 


How do you analyze the work performance data related to relationships? You should have established in your 
stakeholder engagement plan some measurable performance metrics regarding stakeholder engagement. You might, for 
example, use one of the following data analysis techniques to help you figure out if adjustments need to be made to maintain 
stakeholder engagement: 


+ Root cause analysis 
+ Alternatives analysis 


+ Stakeholder engagement assessment chart 


Work performance data and metrics are useful for analyzing the quality of relationships, but keep in mind that some 
of this assessment will also be subjective. 


Think About It. Here’s a scenario: An activity is behind schedule because a stakeholder hasn’t provided a needed 
F component. This delay might point to a problem with stakeholder engagement or a different issue. You should 


ER analyze and work to address the problem and improve the situation, as in the following example. 
Stakeholder not returning Why? Root cause analysis results: 
phone calls? > How can we engage? > They have too much work 

E. Go to next analysis 
Stakeholder engaged but X Revise strategy 
having trouble providing v Reevaluate work assignments 
the needed work? x Reevaluate time estimates 


FIGURE 14.10 Analysis of stakeholder engagement issue 366 
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In figure 14.10, the conclusion is that the strategy and time estimates are fine but the work assignment has to be 
re-evaluated. We do these types of evaluations informally all the time. Just be sure you are not forgetting any artifacts that 
need to be updated. If the person wasn’t answering their phone because they are never at their desk, for example, you may 
need to change the strategy in the stakeholder engagement plan for working with this type of stakeholder in the future. 


14.4 Exercise 

Read the following scenario and write down an analysis of the information that would be useful in answering an 
exam question based on this scenario. For example where are we in the project management process (initiating, 
planning, executing, or monitoring and closing)? What other information can you gather from the scenario? 


Your analysis may not match ours exactly but make sure you feel comfortable with your answer and ours. The goal 
is to practice quick critical thinking. By practicing analyzing scenarios, you will be better prepared to do it quickly 
and confidently during the exam. 


Scenario. A project manager notices someone has become less involved in the project. The stakeholder gave 
helpful opinions on the earliest deliverables, but now they are less involved in the project. The project manager 
contacts the stakeholder to say, “I miss your feedback and always appreciate it. Is there a reason for less input from 
you? Is there anything I can do to support your further involvement?” 


Answer 

Analysis. We are in executing (since there have already been deliverables produced). With more information we 
might determine we are in monitoring and controlling. We could be using a predictive, adaptive, or hybrid approach. 
Communications should be personal (a phone call or visit versus email, for example). Wording and tone of voice 
should be carefully considered since we want to encourage the stakeholder and not offend them. 


Communication 

Communication plays a large part in helping the project manager discover and correct engagement problems. To maintain 
strong engagement and relationships with project stakeholders, the project manager needs to use whatever methods are 
best to work with stakeholders. They need to use the appropriate communication method that works best for each 


stakeholder. Some like texts, others like calls, still others prefer face-to-face communications. 


Interpersonal and Team Skills 
The project manager can of course ask questions like, “How are things on the project going?” But assessing the strength of 


relationships with stakeholders and of their engagement with the project often requires more complex communication. 
Interpersonal skills will help identify issues or concerns that need attention. To further understand how stakeholders feel, 
use skills in these areas: 


+ Asking questions and active listening e Facilitation 
+ Attention to tone of voice and body language + Mentoring 
+ Emotional intelligence + Negotiating 


+ Leadership 
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Artifacts of Monitor Stakeholder Engagement 
The purpose of monitoring stakeholder engagement is to ensure that the implementation of stakeholder strategy is 
happening as planned and is meeting stakeholder requirements. The project manager and the team will have work 
performance information with which to decide if a change is needed to stakeholder engagement strategies and tactics. As 
changes occur there will likely be a change to project artifacts. Monitoring stakeholder engagement results in: 

* Work performance information—an analysis of work performance and validating data about individual and 

group engagement 

+ Change to improve engagement of some stakeholders through different or revised strategies and tactics 

+ Updates to the project management plan 

* Other project artifact updates, such as: 


V Stakeholder register 4 Issue log 


y Risk register y Lessons learned 


Stakeholder Engagement in Agile Environments 


Predictive and adaptive environments have many stakeholder engagement philosophies and practices in com- N, 
mon, although they manifest differently in agile versus plan-based approaches. So far in this chapter we have J 


put a particular focus on the following agile practices in the context of the Process Groups model. Here we’ll A 
elaborate on each a bit more: Focus 


e The product owner The product owner is an agile team member whose specialty is prioritizing the backlog. The 
product owner represents value management for the project. They collaborate with the development team to prepare 
prioritized backlogs sufficient to develop small increments of product with each iteration. This process ensures the 
continuous delivery of value to stakeholders. During an iteration the product owner answers questions for the 
development team and prepares the backlog for the next iteration. As an integral team member, they participate in 
planning meetings, iteration reviews, and retrospectives. 


e Personas This concept was described earlier in this chapter. Personas amount to an understanding of the old adage 
that “walking in someone else’s shoes” helps us understand them a lot better. In this way team members can get a 
better feel for and understanding of what each stakeholder (or stakeholder group) needs from the product. 


¢ Stakeholder engagement planning We said previously that stakeholder engagement plans are often informal on 
agile projects. This is because stakeholder engagement strategies and tactics are built into the iterations cycle. The 
project manager and team design, build, review, and deliver in constant collaboration with the customer. 


Also mentioned in this chapter are the following concepts related to the ECO’s People domain. The following skills 
are completely relevant along the spectrum of plan-based to agile and hybrid approaches, and are covered in more detail in 
the People domain section of this book. 


* Conflict management + Facilitation 


* Emotional intelligence + Negotiation 


Also from the People domain, the following are described as more particular to agile practices. 


* Knowledge sharing and knowledge transfer + Participatory decision making 


Agile Information Radiators 

Information radiators are large visible displays of project information, typically appearing in the team’s work area. The 
purpose is to make it easy for the team to work together and give easy access to the information to other stakeholders. 
Some of the examples below are illustrated in this chapter and others are explained in more detail in other chapters. 


* Kanban boards (storyboards) e Continuous integration views 


+ Release maps * Burndown/bumup charts 
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Kanban Boards 
“Kanban” is a Japanese word meaning “signboard” or Story Task Taskin Task Story 
“billboard.” Kanban boards can be used for many things in Ready Ready Progress Done Done 
agile, and they are perfect for sharing information with 
stakeholders. Figure 14.11 illustrates a board showing 
work in progress that uses sticky notes to describe stories 


to be built. It is low tech and easy for a co-located team. As 


the stories move through production from start to finish 


the sticky notes are being moved from a “Waiting” column a 

to “Design,” “Develop,” “Unit Testing,” “Integrated 

Testing,” and “Completed.” How the columns are named is FIGURE 14.11 Kanban board (story board) 
tailored by team and project, but the board displays the showing work in progress (co-located team) 


status of all work currently in progress. This makes it easy 
for any stakeholder to see how work is progressing. 

There are electronic tools that serve this function. Digital Kanban boards are becoming more common since teams 
are more geographically distributed. 


Agile Definition of Done 

Agile’s careful attention to the “definition of done” is related to scope management. In stakeholder engagement it is 
important because it ensures a common understanding of “done” for each story, for all stakeholders—team and customer 
alike. Each story on an agile project must have a definition of done, often talked about as being “on the back of the story 
card.” To better understand this, take a look at the following example of the definition of done for a book chapter. 


Example product increment: The Introduction chapter of a book, draft 1 (of 2). 

Definition of done for Draft 1: 

+ Draft complete + Line-edited 

* Reviewed for content (team and customer) + Post-edit review complete (team and customer) 
* Revised for content 


Agile Modeling 


You have already seen an example of agile modeling. What is a persona if not a model of a particular type of user of the 
product? Other types of agile modeling focus on the product. Product modeling includes but is not limited to the following, 
which are commonly used with predictive approaches too: 

+ Use case modeling + Wireframes 

+ Process models + High-fidelity prototypes 

+ Low-fidelity prototypes 


With the exception of high-fidelity prototypes the emphasis is not on the exactness of the model but on the 
communication between the team and customer as they create the model together. In communicating to create a model 
together the customer gets a better idea of what their needs are and the team understands better how to build it. Following 
are examples of the models just mentioned. 
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Figure 14.12 shows a use case diagram for a workforce tracking system. This type of model shows the product (a 


system) in the middle and actors (users of the system) on each side. The lines indicate parts of the system a particular user 


will interact with. Can you imagine how much better this model would be if the team worked on it with the users of the 


system rather than if they had just created it themselves using their own assumptions? 


Workforce Tracking 


Worker Payroll System 


a 
HR Specialist 


Worker Manager 


Union Management 


FIGURE 14.12 Workforce tracking system use case diagram 


Figure 14.13 is an example of a low-fidelity prototype of a website for the patient account information on a clinics 
patient portal site. It acts to help envision process flow for using the page too. 


Account Info 


User is logged in Baht na Homepage 
email 

Left Nav. 

Pa ol Log Out 


FIGURE 14.13 Process flow for using a page on a clinic's web page portal 
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The following process flow diagram illustrates a process flow for a clinics paymént process (figure 14.14). 


Finance 


Finance 


FIGURE 14.14 Process flow diagram for payment processing 


Patient 
Pay Bill 


Insurance Co. 


Pay Bill 


Finance 
Patient i 
Pay Bill Finance 


Finance 


Figure 14.15 shows a low-fidelity prototype for the home page of the clinics web page client portal. You can imagine 


a friendly exercise with a whiteboard and the customer here. 


1 Home 
V My Health Info 


4aCommunications 


a Appointments 


$ Billing 


£! Library 


Search 


IP 1 


| 


Welcome [First Name] 


My Health Info 

Health Summary 

Test Results 

Medications List 

Communications 

Inbox 

Request Prescription Renewals 
Appointments 


Schedule an Appointment 
Cancel an Appointment 


Logout 
Home 
Preferences 


Help 


FIGURE 14.15 Low-fidelity prototype for a patient portal 
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Wireframes can be created with software to mock up what a software product will look like. Figure 14.16 illustrates a 
wireframe. These are especially helpful because it is difficult for customers to picture how a computer program might be 
laid out. 


Search 


Tie or Actor Ti Genres v 
P Movie Name Action 
V Movie Name Drama 

Starring Comety 

The movie is about. A 

on 

P Movie Name = a 
P Movie Name 


P Movie Name 


FIGIRF 14.1 6 Wireframe nf a tnavie rental nite screen 


Putting It All Together 


ee a I a n, 


For the exam, keep in mind that stakeholders are important throughout the project. You need to identify all of them (or as 
many as possible), as early as possible, and plan how to manage their requirements, expectations, influence on and engage- 
ment with the project. You also need to periodically update the stakeholder register as you learn new things about your 
stakeholders and perhaps uncover new stakeholders. You need to cultivate good relationships and communications with 
them, and most of all, ensure that the project delivers their approved requirements and that the features and functions of 
the product and service are easy to use and satisfactory. 

Please revisit the Quicktest at the beginning of this chapter. Have you been able to fill the gaps you identified when 
you began the chapter? Most people still have gaps remaining at this point. Go through the chapter again to review the 
areas you are still unsure about. Then complete the following chapter review. 

Here is an example of working with stakeholders for the construction of a new library. Pay attention to the stakeholders 
involved and how the project manager keeps them engaged. 


Case Study to Build a New Library 

The project manager assigned to build a new library in a small city identifies hundreds of stakeholders, including the 
citizens of the community, town council members, the head librarian and staff, and the mayor of the city. The project 
manager $ research reveals that the mayor ’s term is three years and historically, few mayors are elected for more than one 
term. The head librarian has run the existing library for twenty-five years and grew up in this city. She knows everyone! City 
council members represent various groups and at least two of them are always running for re-election. About half of them 
campaign on cutting city taxes. Although the funding has been approved, keeping the council members engaged will be 
important. 

Many of the requirements have been identified in the project scope statement but the project manager meets with the 
head librarian to ask how they can best support the needs of her and her staff for serving their customers. She reports that 
retired folks, children, and job seekers are the most common visitors to the library, and that there is a need for new 
technology options to support the traditional resources of books and periodicals. The project manager asks the head 
librarian if they can meet weekly during the construction process to stay on top of progress. 

The project manager also meets with several city council members who want to lower taxes to ask their thoughts on 
the current library and its importance to the community. The project manager offers to attend city council meetings every 
three months to report progress. The project manager identifies a local newspaper reporter and asks for space in the paper, 
quarterly, to share progress on the library with the community. The project manager promises to keep the reporter updated 
monthly on news related to the library. y y 2 


FOURTEEN 


14.5 Exercise 
Answer the following questions about stakeholders in the library case study. After you have finished answering the 
questions, look to the next section for a good possible answer to each question. 


Question 


1. 


What additional stakeholders might be considered ? 


2. How important is the mayor as a stakeholder? 
3. How important is the head librarian? 
4. Why did the project manager meet with the city council members in favor of tax cuts? 
5. Why did the project manager contact a newspaper reporter? 
6. How will the project manager monitor stakeholder engagement? 
7. How did the project manager demonstrate servant leadership? 
Answer 


Stakeholders 


The answers to the questions in the following table may not match exactly what you came up with but the one thing 
you should ask yourself is “Have I answered the question adequately in relation to the sample answers given?” 


Sample Answers 


1. 


Additional stakeholders could include: 
+ Book publishing companies 
* Technology and equipment suppliers 
* School admins, PTA (Parent Teacher Association) groups 
Moderate, short term but high influence through public visibility. 
High, she is a long-term community member and the expert on the library’s value to 


the community. 
They will probably be most resistant out of fear that the new library will raise taxes or keep 
them the same. The project manager needs to work hard to get resistant stakeholder to 
support the project. 

Engaging the community will be important and the newspaper is a good way to give 
information and get feedback (letters to editor). 

City council meetings, feedback from newspaper articles, weekly meetings with 


head librarian. 


Meeting with head librarian to ask for help. Community outreach through local newspaper. 
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Section V 


Domain III: Business Environment 


The Examination Content Outline (ECO) specifies that Domain III covers 8% of the exam. The presentation of the business 
environment as a separate ECO domain helps you focus on understanding the organization in which you work and the 
environment in which it does business. Understanding the business and environmental factors are critical to accomplishing 
project objectives for the betterment of your organization and its stakeholders. 

In this section, we discuss delivering benefits and value in the business environment. Do not underestimate the 
importance of this section. Understanding the business environment within which a project operates allows a project 
manager to respond appropriately in order to deliver the benefits and value for which the project was undertaken. 
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l 5 Compliance and 
Delivering Value 


Introduction 


As we prepare this chapter for publication, the first snow of the winter season falls here in the US state 
of Minnesota, where RMC is headquartered. We have been getting used to the cold again, and calibrat- 
ing our heating units to warm our homes while using as little energy as possible. Our coats have been 
pulled from the closets and our winter wardrobes are, hopefully, ready. Now for the first time this sea- 
son many of us are thinking about the immediate commute home or the snow removal chores, or both. 
Many are lamenting fall chores that remain incomplete. There is an endless cycle of changes to the en- 
vironments in which we live and of people adjusting to those changes. We and the environment in 
which we live are inseparable. This is a good metaphor for the project and the business environment. 


Understanding the business environment within which a project operates allows a project 
manager to respond appropriately, in order to deliver the benefits and value for which the project was 
undertaken. It is important to have a sophisticated understanding of the business environment because 
the business environment influences the project. The project and its outcomes also have an influence 
on the business environment. They are integrated and inseparable. Do you consider the business 
environment when managing a project? Do you understand how business environments, internal and 


external to the organization, may impact and are impacted by your project? 


The term “business environment” can mean many things. The first task of domain III in the ECO 
addresses project compliance as it relates to security, health and safety, regulatory, and other policy- 
related requirements internal or external to the organization. It’s important for a project manager to 
elicit all compliance-related requirements. Its’ also important for the project manager to ensure all 
project-related work remains in compliance with those requirements. The second task of domain III is 
specifically for delivering the project’s benefits and value. 

The last two tasks in this domain involve managing change. The third task is about addressing 
external business environment changes as they may impact scope, and the fourth is about supporting 
(internal) organizational change. 

PMI states that this domain makes up only approximately 8% of exam questions, but do not 
underestimate its importance. It has, after all, an entire domain devoted to it. An exam question may 
be on any project management-related topic, including the Business 
Understanding business environmental factors will likely help you on the exam just as they will help 
you in your real-world experience. 


Environment domain. 


Definitions Related to Compliance and Value Delivery 
Following is some basic vocabulary that is used throughout discussions of general management, 
project management, and in this case the business environment. These terms may not be used often in 
this book but for the exam it is assumed you know and understand them. 


QUICKTEST 


Value chain 

Value stream mapping 

System 

Complexity 

Compliance 

- Governmental 

- Societal 

- Organizational 
governance 

- Project management 

Systems thinking 

Value delivery 

Stewardship 

Minimally marketable 

feature (MMF) 

Organizational culture 

Transitional change 
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Compliance 
In a project management context, compliance can mean adherence to: 
* Delivering product scope in accordance with the e Project constraints 
strategic objectives the product is meant to meet or + Project and product requirements 


help meet for the organization and its stakeholders * Guidance from the PMO regarding project 


* Organizational rules and guidance related to health management practices within the organization 
and safety, human resources requirements, and other 


internal operational needs 


(tailored to a specific projects needs) 


+ External regulatory rules and guidance 


Value Chain 
A systematic series of steps that go into the creation of a delivered product is called a value chain. The value chain identifies 
each step in the process from inception to delivery. This is an important concept because everyone’s purpose on a project 
is to seek to deliver value at every step along the value chain. 

Example The product is a homemade apple pie made from fresh local apples. Here’s how the value chain may 
be expressed. 


> en ee SE 


- Deliver 
- Eat 


To orchard Get apples To grocery Get other To home Prep kitchen Prep Bake pie Cool pie 
ingredients ingredients 


FIGURE 15.1 Value chain for pie product 


Value Stream Mapping 


This is a lean concept (more about lean in the “Agile Methodologies” chapter). In value stream mapping a team (in our case 
the project team) visualizes, discusses, and analyzes all steps in a product delivery process in order to eliminate waste and 
gain efficiencies in that process. 


System 
A continually interacting and interdependent group of items or activities. Some parts of a system may work alone or jointly 
with other parts in a system, while other parts work only within the system and have no independent use. 


Complexity 


Projects are inherently complex; they are composed of many interrelated parts. These many interrelated parts stem from 
the characteristics of the project itself and also from interrelated systems that project managers work with on projects, 
which belong to organizations, which belong to society as a whole. This will be explained in more detail later in this chapter. 


Overview of the Examination Content Outline Business Environment Domain 

Before we discuss the tasks in this domain, take some time studying figure 15.2 along with the ECO. Figure 15.2 illustrates 
that people and processes exist within the business environment. For projects and for the exam, thinking holistically about 
everything that is in the ECO is important. 
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Business Environment 


Process Domain - Planning and managing 


People Domain - Leadership and Performance 
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e Project compliance 


Business 


° External business environment changes—impact scope Environment 


+ Deliver benefits and value 


+ Support (internal) organizational change 


¢ Integration: Methodology & practices, planning, 
executing with urgency, changes and artifacts, ensuring 
knowledge transfer for continuity, closure/transitions. 

¢ Constraints: Scope, schedule, cost, quality, and resources. 
Procurement is related in that with it we acquire and 
integrate part of the project's scope from externally. 

¢ Uncertainty: Risk 

¢ Relationships: Stakeholder engagement and 
communications. These are at the intersection of people and 
processes. (See "Relationships ” under People.) 


* Leadership Skills: The backbone of all people FIGURE 15.2 All domains: people and 
domain capabilities. processes exist within the business environment 


¢ Build Performance: Build a high-performance team; 
engage stakeholders. 
¢ Support Performance: Support performance for all stakeholders. 


e Relationships: Stakeholder engagement and communications. Use People domain skills. Provide servant leadership to 
establish/ensure a common understanding and get work done through others. 


ee Think About It. Take out your ECO and compare the tasks in its three domains to the information presented 


in figure 15.2. In this figure we have incorporated the three ECO domains and summarized them. Can you plot 
the corresponding ECO tasks within this figure? Can you naturally think holistically about ECO tasks so that 
thinking about any one task makes you consider others as well? Cultivate that capability for the exam. 


Figure 15.2 encompasses all tasks but also implies relationships between the tasks in the three domains: 


+ The business environment is the larger of the three circles because people and processes exist within it. A project exists 
within this environment as well. A holistic view of projects and the environment in which they exist is essential to 
success as a project manager. 

+ The Process domain contains tasks that describe the work enabled by the technical project management skills and 
processes. It includes tasks related to planning and managing integration and a projects constraints. Remember that 
all project constraints must be balanced on a project. This means prioritizing them against one another to resolve 
competing constraints. 

+ The Process domain includes planning and managing uncertainty, meaning the risks (both opportunities and threats) 
are inherently part of any project (and any business environment). 


+ Stakeholder engagement and communication on projects each have processes and therefore have associated technical 
project management skills, but like everything else on a project they do not stand alone. The skills needed from the 
People domain underpin the relationships necessary to be successful in these areas. 

+ The People domain is about acquiring and using skillful servant leadership capacities in order to build and support 
performance for the team and also for all other stakeholders associated with a project. We are all in it together. 

+ Again, even with the best process and technical management skills, there can be no success without the skills described 


in the People domain. People domain skills enable the successful relationships needed throughout project work and 
throughout projects, to be successful. 
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Now let’s take a closer look at each of the four Business Environment domain tasks. These tasks encompass all 
processes in the Process Groups model and all domains in the PMBOK* Guide. 


Domain III All processes All domains 
Taskl 
Plan and manage project compliance Also see sections 2 and 3 of the 
Standard for Project Management 
Task 2 


Evaluate and deliver project benefits and value 


Task 3 
Evaluate and address external business 
environment changes for impact on scope 


Task 4 
Support organizational change 


Planning and Managing Project Compliance 


Like the term “business environment,” the term “compliance” can mean many things. 
Compliance regulations, rules, and guidelines can come from many places: a govern- 
mental regulatory body, an organization’s management structure, a particular manager or 
director, a project manager, a project charter, or a team charter. Here are some compli- 


ance categories: 


Business Environment (Organization) Project (Manage & Control) 


+ Health and safety + Project and team charters 

e Security + Project constraints (scope, schedule, 
+ Financial cost, quality, resources) 

+ Regulatory * Quality 

+ Environmental e Procurement 

* Social + Agile processes and methods 

+ PMO policies, procedures, etc. + Performance measurement baseline 


The above table is just an example of categories in which compliance requirements may fit. These categories are not 
mutually exclusive. For example “PMO policies, procedures, etc.” could easily fit into either of the columns in this table. 

Example The PMO exists to support project management and so provides project management guidelines to follow, 
such as monthly project status reporting to the executive committee. PMO policies and procedures, many of which are just 
guidelines, are related to a particular business environment within an organization. The project manager handles compliance 
with the PMO’s guidelines as necessary on their project. But these guidelines are developed within an organization in the 
context of the larger external business environment, with its market and societal forces affecting the organization and 
its projects. 

Next, we'll discuss compliance as it relates to the business environment. These are the compliance concepts that can 
be most closely mapped to domain III, task 1 of the ECO (plan and manage project compliance). 


Business Environment Compliance Requirements 

As we’ve said before, it’s important for project managers to elicit all compliance requirements. Compliance requirements 
from the business environment generally belong to one of two subcategories: compliance requirements related to 
government regulations and societal norms (which are external to the organization), and compliance requirements related 
to the performing organization’s internal structure and governance. 
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Governmental Regulations and Societal Norm Compliance 
There is no doubt that regulatory compliance is mandatory. Regulatory compliance is the sole impetus for many projects, 
and it is at least a component of many more. Examples include: 


+ Existing organizations of any type must research legal and regulatory aspects of any project selected by the organization. 

+ New regulations mean all organizations of a certain type must comply and this may require projects to implement 
product, process, or service changes. 

+ Changes to existing regulations mean compliant organizations must charter projects to undertake the work to remain 
in compliance. 

+ A new organization must include regulatory research and compliance projects along with other start-up- 
related projects. 


+ An organization that has been found to be noncompliant by a regulatory body must comply by a certain date. 


Regulatory compliance often includes significant work to study and interpret the relevant regulations, research and 
determine their impact to the organization and/or its projects, further work toward validating what has been learned 
before business requirements can be elicited, and a solution can be designed and implemented. The following practical 
examples of regulatory compliance situations can help you understand regulatory requirements in various 
organizational contexts. 

Examples 

+ A healthcare organization that must ensure an upcoming technology upgrade project for their patient portal includes 

requirements for compliance with HIPPA (Health Insurance Portability and Accountability Act) regulations. 

+ Abank that wants to change a key business process must include in their project a compliance analysis and requirements 

elicitation phase. The resulting deliverables include compliance requirements for each related project in the program. 

+ A US state must prepare an annual report on violations of the national primary drinking water regulations incurred by 

public water systems. 

+ A new school that is opening must research, elicit, and implement regulatory requirements associated with their 

responsibilities related to civil rights compliance in child nutrition programs. 


In addition to regulatory requirements, organizations must seek to understand and comply with acceptable societal 
norms. These could include things as seemingly obvious as a dress code in a particular industry—compare working at a 
bank versus planting trees for a landscaping company; think of constructing a building and immediately a hardhat comes 
to mind for many. Norms also include things that we may think should be taken for granted, but this is not always true. This 
includes the “norm” of a safe and friendly workplace environment. Everyone would agree with this expectation, yet the 
news is replete with stories about violations of this “norm.” 


Societal norms change and are always evolving. An example affecting the organization and society at large is evolving 
environmental practices related to everything from recycling to green building and _ wildlife-friendly landscaping, to 


creating product development, manufacturing, and support practices that are more environmentally sustainable. 

Can you see that no one practice fits neatly into a single governance category? For example, your organizations 
governance may be ahead of the larger society in developing more environmentally sustainable product development 
practices, which will in turn affect how new product development projects are governed within your organization. 
Eventually your organization š practices or similar ones may become regulatory in nature as new environmental regulations 
are passed. Everything is connected. 


Organizational Governance Compliance 
Some types of compliance are related to internal organizational rules and guidance already in place. Such rules and guidance 


may be related to internal human resources and health and safety policies and procedures, for example—some or all of 
which will be tied to regulatory governance. Other organizational governance may be based on the hierarchy, culture, and 
operations of the organization itself. These will include all the policies and procedures set up by the PMO to help portfolio, 
program, and project managers. Examples of organizational governance practices and artifacts include the following: 
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* Tools, templates, and procedures set up by the PMO for project management, for example: 
>/ Project charter and scope definition templates 


+/ The PMIS (project management information system) to be used for saving project artifacts and project 
knowledge sharing 


y Guidance on functional and project managers managing resources on projects 


y Documented practices specific to the types of project life cycles and development approaches used by the 
organization, from predictive to agile or hybrid 


+ Management organizational governance relates to: 


y Procedures and communication guidance for taking PTO (paid time off) 
y Guidance and established practices ensuring employees fair and equitable treatment 
y Guidance on how to lodge a complaint against management 


y Suggestion for the company’s continuous improvement in any area of the business 


Project Management Compliance 

The organizational practices and tools supplied by the PMO are taken into consideration by the project manager as they 
tailor governance to their specific project, starting in initiating and planning. The following list gives examples of compli- 
ance requirements specific to a project. Some of these compliance requirements come from the organizational environ- 
ment while others are specific to skillfully managing a particular project. 

e Project governance must stem from organizational governance. A project’s governance must be created with awareness 
of and in compliance with organizational guidelines and rules applicable on the project. 

Example A project manager needs to understand and use company policies and procedures regarding the hiring 
of new employees or contract employees for the project. 

+ The project manager needs to integrate regulatory compliance requirements into project activities. 

+ Following procedures for working with the procurement department for help with project procurements is usually 
necessary. There may be approved suppliers and subcontractors the project manager will need to use on their project. 

+ Integrated change control procedures and change request templates are typically tailored to a project but necessary to 
change management efforts on plan-driven projects. 

+ On agile projects the product owner typically presides over change requests related to scope, while the team works 
together on changes to methods of building the product and the project manager ensures that the agile methods in 
play are understood and being followed. 

+ Project managers must exercise conscientious stewardship over the project so it can meet its requirements and 
objectives while remaining in compliance with project constraints (scope, schedule, cost, quality, risk, resources). To 
do this, balancing competing constraints is often necessary. 


Delivering Value 


When you are handed a new project to manage, do you automatically say to 
yourself “let me see what value this project is meant to deliver to the organi- 
zation and our stakeholders?” Probably not in those words, but you may do 
the equivalent of this. You quickly look for the reasons your organization 
selected the project (the business case), and what deliverables and outcomes 
the project needs to deliver (project goals, objectives, and value). You are 
also thinking about how you can do your best and inspire others to do theirs 
so that the project will be successful. 
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Systems Thinking 

Project managers need to understand and practice systems 
thinking. Organizations exist as systems of value delivery for 
their stakeholders. To that end any organization—company, 
non-profit, or governmental agency—exists within the 
context of many systems working together for mutual benefit. 


Stakeholders/ 
Customers 


Figure 15.3 illustrates some of the many systems within Locale, 
which an organization exists and interacts, to deliver value to Region, Economy, 
its stakeholders. Comey: 
As discussed earlier in this chapter, organizations 
support compliance based on the regulatory environment. 
Organizations also interact within a variety of contexts: the 
location in which it operates, markets and competition, avail- 
able technologies, and current economic and regula- 
tory forces. Marketplace & Techistogy, 
Competition Landscape 


Now, you probably already know why projects exist. 


Think About It. Projects exist to create and deliver 
: very specifically defined value to the performing Regulation 
i organization and its stakeholders. Like an 
organization, a project is a system of value delivery. 
Each project is undertaken to deliver a subset of the total 
value the organization seeks over time to deliver to its 
stakeholders. 


FIGURE 15.3 Organization and external 
systems it interacts with 


Figure 15.4 shows an organization as a system with 
other internal systems that act alone and jointly with the 
organization. 


Examples are: 
The PMO 
Governance * Portfolios, programs, and other projects 
* Operations 
+ Governance (organizational a project) 


Subsystems of the organization help it deliver its 


intended value to its stakeholders (and society at large). 


_ C 


FIGURE 15.4 Organization and internal systems 
that interact with it 
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ORGANIZATIONS are complex systems that exist to deliver value to their stakeholders 
(and greater society) and thus achieve their own strategic and tactical goals. 


Organizational governance is a system within the organization that exists to support the delivery of value to 
stakeholders. Governance is made manifest through its established framework of policies, procedures, 


practices, and other guidance relevant to the organizations sustainability. 


Subsystems within an organization deliver value: PMO provides a project gover- 

+ Projects, programs, portfolios and the PMO that governs them nance framework (based on 

+ Products and services (results of portfolios, programs, and organizational governance) to 
projects) standardize on: 

e Operations (support of products and services; sustaining functions e Tools, methods, templates, etc. 

like human resources, finance, and other functional groups) e Guidelines for compliance 

These must work alone and jointly. e Guidance, resources 

Project governance guides Program governance helps direct Portfolio governance directs 
project management activities guidance among allied projects guidance among allied programs 
toward the goal to create the and operations work. and operations. 

product of the project. + Based on organizational and + Based on organizational and 

+ Based on organizational and PMO governance and guidance operations governance 

PMO governance and guidance + Tailored to the program and its + Tailored to a portfolio’s current 

+ Tailored to the project projects context 


The Project As a Value Delivery System 

We have established the project as a value delivery mechanism that as a project manager you have to see through systems 
thinking. We have also established that a project as a system is a subset of multiple other systems, not least of which is the 
organization in which it is undertaken. Let’s focus now on the project as a system of value delivery. A project creates 
deliverables meant to both produce outcomes and be sustainable. 

Example 

° Product Scope A new library service is needed to help unemployed people use the internet to apply for jobs. 

° Deliverables Computer lab upgrade, special training for library staff who will coach patrons who need help with 
the technology. 

e Outcome The number of people getting help with job applications will increase by X%, as measured by library staff 
and quick patron exit surveys. The library has data analysis results showing the current number of people getting help 
with job applications. This information can be compared to a similar analysis, monthly after project completion. 

¢ Benefits management plan This includes the number of people benefiting from the computer lab, the number of 
books checked out, and community survey results, to name a few. The service will be re-evaluated in six months and 
then a year to evaluate success and assess additional needs of the computer lab or service. 


15.1 Exercise 

Delivering value to a large number of stakeholders is difficult. One technique often used is a survey or questionnaire. 
Imagine the library project team wants to send out a questionnaire to the citizens who will have access to the new 
library, to determine the potential value. What questions would you ask of these “users” of the library? Write your 
answers in your Exercise Notebook before reading the possible answers below. 
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Answer 


Here are some examples of questions you may have come up with. 
+ How often do you visit a public library? 
+ What are the services you look for in a library? 
+ What type of equipment do you expect to use in the library (e.g., computers, tablets, printers) ? 
+ How much time do you normally spend in the library during a visit? 
+ What types of books are you most interested in (e.g., fiction, childrens, history)? 
+ Do you prefer hard cover or paperback books? 
+ Do you enjoy working with a librarian for book recommendations? 
+ Would you enjoy refreshments being available in the library (e.g. coffee, sodas) ? 


+ Do you prefer a large reading room or smaller nooks? 


Process Analysis 


Think About It. At the start of this chapter we defined the term value stream. Lets look at the value stream from 

ood figure 15.1 again, for making a pie from fresh, gathered ingredients. We’ll analyze it in terms of value delivery. The 
following can serve as an example of how you go through planning and managing any project in order to deliver 
the promised value as efficiently and effectively as possible. How might we make this process more efficient? 


ee a a 


To orchard Get apples To grocery Get other To home Prep kitchen Prep Bake pie Cool pie - Eat 
ingredients ingredients 


In the following discussion, people are shown in italics and activities are shown in bold. 


+ There seems to be a lot of extra driving involved if Pie Maker is doing all this. That’s a lot of Pie Maker's time plus 
possibly wasted energy. Is there anyone else who can help more efficiently? 


-/ Yes. Team member Grocery Getter says they can go to the grocery every day and can stop for Get other 
ingredients on the way To home, since they are going there anyway for activities related to another project. 


-/ Grocery Getter will stop on their way To home. 


y That removes waste from two activities. It makes To grocery less resource intensive and eliminates To home 
since that car trip was going to happen as part of operations anyway. 


>/ It also saves some of Pie Maker ’s time, plus saves other resources (gas, car wear and tear). 
+ What about the Get apples activity? Can we eliminate that activity and just combine Get apples and Get other 
ingredients? 
y No. There is a lot more value in Get apples if they are picked fresh from the orchard. That value may not be 
easily measurable, but that activity is worth its value. 


y Our customers will be more satisfied with this choice. 


+ Because Grocery Getter is saving Pie Maker time, Pie Maker concentrates more on continuous improvement to the 
Prep kitchen and Prep ingredients activities. 
* What about Grocery Getters time? Why don’t we just order groceries online and save more time? 


y Grocery Getter can pick the ingredients they know are the best. 
y It will cost more for delivery. 


y We market our products as containing fresh ingredients, gathered ourselves. Let’s be true to that promise 
to customers. 
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A true value stream mapping effort would have decomposed every activity in more detail than shown here. 
Nevertheless, in this scenario the project manager and team were respectful and conscientious stewards of the time and 
other resources needed in the “make fresh apple pie” process. They were aware of how another project could affect theirs 
and used that information. Team members contributed ideas to eliminate waste and gain efficiencies in resource use and 
adding value. They acted with integrity in keeping with their assurances to customers and practiced continuous 
improvement as part of the process. 


How We Deliver Value on Projects 
People are assigned to projects largely for their technical skill, but technical skill alone does not make anyone successful. 


The project manager and the team must work together to deliver the promised value of the project and product scope, and 
that takes interpersonal and team skills. A knowledgeable, talented, and conscientious project manager works to deliver 
value on projects in everything they do, and the same can be said of the team. All work together to deliver the product of 
the project and to set up its transition to operations so that the product has the best chance of providing the continued 
benefits for which it was created. This book discusses in detail the many ways in which the project—as a system—does 
this. Let’s turn to the principles that can guide these behaviors for the project manager and team. 


Think About It. Project management and delivery behaviors are informed by People and Process domain skills, 
but they should also be informed by a set of principles. As a connection to the business environment, and to the 
working environment and your place in it, think about the principles that may guide the behaviors of the project 
manager and team as they work avidly to deliver value through project and product scope. PMI has suggested 
twelve project management principles in the current Standard for Project Management that is published with the 
PMBOK* Guide, Seventh Edition. You will find most or all of them familiar. 


Project Management Principles 


Stewardship This is about acting with care and integrity, and establishing and maintaining trust. In managing projects for 
the organization and the larger business environment, working together is easier on everyone when a trusting and caring 
environment is created. This is also about the careful use of resources entrusted to the project manager by the organization 
and the stakeholders. 


This principle can be practiced within the organization by ensuring the projects’ alignment with the organization’s 
strategic objectives. Project managers can also be careful stewards of the organization’s finances; they can simply treat other 
team members well and use their authority with care. 

Even though long-term product sustainability is typically technically part of a particular projects scope, project 
managers should understand the entire product life cycle and can always look to contribute to it through smooth and 
forward-looking project transitions. Beyond the organization project managers can be careful stewards of environmental 


resources. They can also improve the professions they practice as part of the larger social community. 


Team As servant leaders, creating and ensuring a collaborative and safe team environment fulfils the spirit of this principle. 
Safety and the resulting trust allows each team member to contribute their unique talents and skills, single and jointly with 
the team. Other factors supporting safe and collaborative team environments include team agreements (for example, a 
team charter), organizational structures, and processes servant leaders can help put into place. 


Stakeholders This is all about how stakeholder engagement is managed. Project managers can engage stakeholders 
proactively to the degree needed for success of the project and of all project stakeholders (including the team and project 
manager). 


Value We have already talked about a project as a system of value delivery. Project managers can continue throughout the 
project to ensure that it and its product are aligned with the organization’s business objectives. 


Systems Thinking Your understanding of systems and systems thinking can now help you to understand that this prin- 
ciple is about the project manager’s constant proactive response to a system’s dynamic and changing circumstances. 


Leadership Practicing servant leadership, fostering a collaborative team environment, and carefully balancing the needs 
of individuals with that of the group is the spirit of this principle. 
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Tailoring Everything you have read of the previous principles speaks to the need to tailor the approach to the project, 
project management practices, and leadership to each specific project and its needs. Yes, the project manager will settle on 
a specific development approach, be that plan-driven, agile, or hybrid. However, within that context all specific practices 
used on a project should be subject to review to ensure it is useful to the project at-hand. 


Quality A focus on quality will ensure that the product of the project meets project requirements as agreed to with key 
stakeholders. Categories of quality requirements may include: 


¢ Performance Meeting these requirements ensures the product (or service) functions as intended. 
¢ Conformity This answers the question about the product: “Does it meet specifications and is it fit for use?” 
¢ Reliability means consistency of performance to requirements. 


¢ Satisfaction means the functioning, useability, and user experience of the product is to the 
customer s’satisfaction. 


e Uniformity Are the deliverables uniform with others produced in the same manner? 


¢ Efficiency means can the project manager and team, and does the project manager and team, achieve best 
product performance with the least inputs and efforts? 


¢ Sustainability means creating products with positive impacts on socioeconomic factors and with 
environmental sustainability. 


Navigate complexity Related to tailoring, the project manager should continually evaluate their approaches, methods, 
and plans on the project to ensure they are in line with project (and organizational and societal) complexity. This also 
includes enabling a successful project (and arguably, product) life cycle. 


Risk This principle is about continually evaluating risk and the risk response plans and executions, to ensure that they are 
still a good fit for the actual project risks and their impacts. 


Adaptability and resiliency As a project manager, you need to build adaptability and resiliency into your own project 
management practice and help enable adaptability and resiliency in the team and the organization. 


Enable change to achieve the envisioned future state Every project begins with a current state. Every project is meant 
to end with a desired future state brought about (at least in part) by the product of the project. Project managers enable 
change to achieve that envisioned future state by preparing the stakeholders impacted by the project. They can only do this 
by building effective transitions, to be carried out as part of the phase and project closing activities. 


Have you noticed that two of these principles are about navigating complexity and enabling change? These are aspects 
of project management that are not often given much explicit attention but which project managers focus on implicitly 
throughout a project. The next two sections of this chapter address the Business Environment domain tasks that give 
complexity and change the needed attention. 


Evaluate and Address External Business Environment Changes for Impact on Scope 


We have discussed in some detail the environments external to a project and their potential impacts. What happens as 
changes occur to the external environment after the project has begun? In a predictive environment the challenge is to 
continually ensure that the benefits agreed to during initiating and planning remain valid, and that the developing solution 
will deliver those benefits. Small changes to the business environment may simply prompt small, approved changes as they 
arise. On the other hand, changes maybe more involved and require reprioritization or reassessment and redefinition of the 
projects’ defined scope. A scope change will also often necessitate changes to the schedule, budget, or other project con- 
straints. 
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For the types of projects that can use an agile approach, adaptive environments are set up from the start 
to adjust relatively easily to scope changes. It is a benefit of planning a project and building a product iteratively 


and incrementally. The concepts of building Minimally Marketable Features (MMFs) and delivering a aie 
Focus 


Minimally Viable Product (MVP) summarize these benefits: 
¢ MMF (minimally marketable feature) Think of an MMF as the smallest feature that can be released into the 
marketplace, which stakeholders need or will find useful. 

Example What if the US decided to no longer use Daylight Savings time? All computerized clocks (like those in 
smartphones) would have to have a feature update pushed to them at the appropriate time so they will remain accurate. 

¢ MVP (minimally viable product) An MVP is a version of a product with just enough features to make it useful. 
The most critical features can be used by early customers. 

Example Many new cars now have adaptive cruise control, which helps the driver stay far enough away from the 
car in front of them. This can decrease the likelihood of crashes. While this is a full-fledged (not minimally viable) 
feature on new cars with drivers, it has capabilities that are in the “minimally viable” stage of the driverless car product, 
which is still generally thought to be only experimental. 


MMFs are delivered on a regular basis as updates to already existing consumer products—especially those that utilize 
software. This allows the project team to learn the most about the customer and business environment with the least 
possible effort, incrementally. The MVP allows the project manager and team to see how the increment of the product 
appeals to the customer and how the customer uses the product. The team then uses feedback to update the product to 
increase its capabilities or even cancel the project entirely as necessary. 

One of the many benefits of building products incrementally and iteratively is that as the external environment 
changes, agile project managers and teams can more easily change the scope of their projects to adjust to these changes. 
Nevertheless, any type of project has to be managed carefully with the external business environment in mind to ensure 
that the project 's scope remains valid and will have the value to the customer of the product represented at the beginning 
of the project. If the product scopes value changes, then project and product scope must also change. 

The industry you are working in, technology, regulations, geopolitical factors, and marketplace sectors can all 
experience changes that will impact your project. 


7 Think About It. Consider these examples of environmental change: 


@ * Your major project is to develop battery technology for electric cars. A competitor releases a battery to the 
a market with a capacity marginally exceeding the one you are set to achieve with your project. You will need to 
lead a project change effort within your organization. 


+ A natural disaster affecting the region from which your project is being managed will affect your project. Risk 
management planning has to take this into account. 


+ A regulation governing your product has expired so that your project can begin closing sooner than expected, 
having accomplished all work that still aligns with the project charter. You can transition the product as-is to 
the marketplace. 


How do you handle environmental changes? Regardless of the type of changes taking place on your project or in your 
environment, the process is the same! 

1. Have a high level of sophistication about your products and services, your organization, and your environment. 

2. Maintain awareness and monitor the possibility of change of any kind. 

3. As potential changes are identified, evaluate the changes and their impacts. 
4. Plan your response. 
5 


. Lead the team in operating within the organization and the project to support your planned response. 
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Part I: Review the graphic below with some of the external organizations or systems within which the new library 
will exist. Can you think of one change that might impact the project from each of these? 


Government Publishing 
regulations companies 


Local 
neighborhood 
and roadways 


Competition 


City economy 


External 
Patrons 
Technology 
City economy 
Competition 
Local neighborhood and roadways 
Government regulations 


Publishing companies 


Answer 


Patrons 


Technology 


Potential change 


Here are some possible answers. You may have come up with some additional potential changes. 


External 


Patrons 


Technology 


City economy 
Competition 


Local neighborhood and roadways 


Government regulations 


Publishing companies 


Potential change 
More patrons driving to library than expected, resulting in parking 
problems and complaints. 


New social media site becomes available, patrons want to use it on library 
equipment, but it has some offensive content. 


The city does not have enough funds to support the library maintenance 


costs. 
A new bookstore opens near the library. 


Crime in the area of the library has increased. 
Traffic problems. 


A new mask mandate is put into place for all government and public 
buildings. 


Books will begin to only be available on tablets or mobile devices. 


Compliance and Delivering Value 
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15.3 Exercise 

Part Il: Think again about the graphic in the previous exercise, with some of the external organizations or systems 
within which the new library will exist. While managing the new library project, what should the project manager 
be doing to monitor the external environment for changes? Write your in your Exercise Notebook before looking 
at the possible answers below. 


Answer 


Possible answers: 
+ Contact library directors in other communities to learn about their successes and challenges 
+ Make contacts with publishing companies and check in with them every couple of months. 


e Post articles in local newspapers and websites with status reports for the project, offering an email address for 


patron questions. 
+ Respond to questions from patrons, city council members, the mayor, etc. 
+ Attend city council meetings, neighborhood community meetings, and city planning meetings. 
* Read the local news, looking for other projects nearby that may conflict with the library. 


e Check with the construction company on current building regulations and compliance procedures 


Support Organizational Change 


This ECO task is about supporting changes to a project that may result from changes within the performing organization, 
and changes within the organization that may result from a project or its product. Organizational culture is as important to 
consider as the type and magnitude of a potential change to the project, the organization, or both. 


Organizational Culture 
Projects are impacted by and have an impact on internal cultural norms and organizational management policies and 
procedures. These factors are increasingly important in global organizations in which team members are often working 
from different and sometimes remote offices, each with its own culture. Employees of any organization must be part of the 
organizations ‘culture and comply with its policies and procedures. At the same time project managers must be respectful 
of everyone on the project and the multiple cultures in which the people assigned to the project must operate. Project 
managers should be able to adapt their leadership approach by understanding as much about the team and stakeholders’ 


cultures as possible. 

Internal organizational changes may require changes to the project team, rework, schedule changes, project scope, or 
even cancellation of the project. Understanding organizational culture, politics, and governance will enable the project 
manager to make needed changes within their projects in ways that minimize negative effects and keep the project moving 
forward. In the case of a cancelled project the project manager must be able to lead the transition smoothly. 


Think About It. It is important to consider organizational culture not only when initiating a project, but 
throughout its life cycle. Why? Imagine you’ve planned a project and uncovered key requirements the supporting 
organization didn’t initially disclose. The plan will most certainly need to change to meet the new requirements. 
But why were these requirements undisclosed? Was it an oversight or was there another specific reason the 
requirements remained unexposed? How will the organizational culture be affected by these changes? Likewise, 
how will these changes affect organizational culture? Will the team support the necessary changes to the project? 
Will the customer support the changes? The project manager has to answer all these questions and more in order 


to lead the team toward the right changes. 
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As a project manager, the more you know and understand your organizations ‘culture, the easier it will be to answer 


these questions and provide appropriate leadership to the team in the best interests of the project. Following are additional 


examples of organizational changes that would affect a project: 


. 


Your organization has merged with another company and you will lead efforts to evaluate the continued viability of 
your project within the new organization. 

Your organization has changed directions and your product has become more critical to the success of the new 
organizational direction. You will be given more resources to work with but need to replan the project to finish six 
months earlier than the original plan called for. 

A key team member is leaving the company. You will need to negotiate for a new resource that best fits in with the 
current projects progress point and the current project team’s skills. 

Your organization is closing three of the eighteen offices to which you were planning to roll out a new desktop software 
build. One of the offices being closed was to have the pilot group for the product of your project. You will have to 
replan the project without these offices and plan for and obtain a new pilot group. 


Project Change 


Project change management is discussed in further detail in the “Integration” chapter, but the following is a list of examples 


of good project management practices that will help manage project changes that affect the organization. 


In traditional project management, the progression from rough order of magnitude (ROM) estimating done for 
project selection is re-evaluated during initiation with the development of the project charter. This is followed by 
more definitive estimating using tools like scope decomposition, network diagramming, and three-point estimating 
during detailed planning. Checking detailed estimates against the project charter is important to ensure that 
organizational management s assumptions about the project’s viability remain valid. 

Phase-gate systems for projects allow the team and stakeholders to pause, evaluate, and approve what has happened 
so far on the project and then decide to move on to the next phase. Changes may be made to policies and procedures 
at these milestones that represent updates to the organizations process assets. 


Something is discovered on a project that does not affect the project but may affect another project in the program to 
which the project belongs. Escalating to the other project manager or the program manager will ensure that the issue 
is taken into account for benefit of the organization. 


Integrated change control is the process of managing changes within the project, ensuring that changes to the project 
are necessary and carried out systematically. If change is not managed properly on projects, it will have negative effects 
on the project and thus on the organization. 


Agile project management supports a continual state of project change through iterative and incremental planning 
and product development. This could mean the continual delivery of value to the customer. 


Transitional Change _ 


Why do we do projects in the first place? A project is undertaken for the express purpose of filling a business need to bring 


about change of a specific nature, to the organization and its stakeholders. Before a project starts, an organization or its 


customers are in an environment called a current state. The project is meant to bring the stakeholders to a future state 


defined by the project objectives and encapsulated in the project’s scope and requirements. Project management is geared 


toward building the product of the project. Implicit in the work of a project manager is to ensure that stakeholders can 


make the transition from current to future state with as little disruption to their current operations as possible. By their 


very nature, projects are about creating and managing change. 
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Think About It. However valuable a new solution is, people need help making the transition to it. Following are 
© some examples of how that might be managed: 
aa + A simple change to an already existing software product is built to automatically download on stakeholder 
devices and a pop-up summarizes the changes. 
+ A new software rollout will completely change the way processes are completed in the affected department 
within the organization. The project is part of a program that includes a communications director managing a 
carefully planned communications project while a training director manages an implementation and 
training project. 
+ An already excellent product is being updated with more modem technology. Included in the new product 
rollout is a trade-in and rebate program that gives customers incentives to buy the new product. 


Historically projects in organizations did not give enough attention to transitions between the current state and the 
future state. How would people find value in changes to the way they work without help in transitioning to the future state. 
Today, projects and programs appropriately give more attention to managing transitions than was the case in the past. 

For the exam you will need to understand that the changes brought to users at the end of new product or service 
development projects need to be managed, either as part of the Close Project or Phase process (of Integration Management), 


or as part of a separate project, depending upon the size and complexity of the change. 


Change Models 
PMI has published a framework for change in its Managing Change in Organizations: A Practice Guide (2013). This 


framework is based on five common elements of many change models along with a series of feedback loops. 


+ Formulate the change + Manage transition 
+ Plan for the change e Sustain the change 


+ Implement the change 


Understanding how people react to and adopt change allows organizations to better plan and incorporate changes. 
Impacted stakeholders are internal and external people who need to be made aware of how and why changes affect them. 
A few useful change models are described next. You may see one of these model names as an answer choice in an exam 
question. 


AD KAR Model 

ADKAR stands for Awareness, Desire, Knowledge, Ability, and Reinforcement, which are the five steps that an individual 
goes through to adapt to change. This model was developed by Jeff Hiatt in 2006 when he studied changes in over 700 
organizations. The model helps change management professionals to develop communications and activities for impacted 
stakeholders undergoing change at each stage of their journey. 


8-Step Process for Leading Change 


The 8-Step Process for Leading Change focuses on a top-down approach for the management of medium- to large-sized 
organizations. John Kotter published his framework in 1995 and encourages leaders to generate enthusiasm for the change 
by communicating the vision and identifying company change leaders to influence impacted stakeholders. 


Virginia Satir Change Model 


The Satir Model, first published in 1991, was designed to improve relationships and communication within family units 


and explains how people experience change. It is also used by organizations to plan changes by anticipating expected 
impacts on stakeholders. The Satir Model acknowledges that things often get worse before they get better, but they will 
eventually get better with clear communication and support. Virginia Satir was a psychotherapist working in family 
systems. 


Transition Model 

William Bridges’ Transition Model provides an understanding of how people transition through a change. Transition is a 
psychological process where people gradually accept their new situation after the change. It includes stages of 1. ending, 
losing, and letting go; 2. the neutral zone, and 3. the new beginning. Bridges’ model was first published in 1980 in his book, 
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Section VI 


Pulling It All Together 


This section covers three very different but important topics. Here, we provide some important tips and tricks for passing 
the PMP* exam on your first try. While these tips have evolved over the years, Rita Mulcahy provided them based on her 
vast knowledge of the exam experience and they have helped thousands of our students ever since. We recommend that 
you revisit these tips the day before your exam because the information they provide is invaluable. 

This section will also give you a deeper dive into agile methodologies. Knowing the principles behind agile will help 
you understand it better. 

Finally, we give you more information about PMIs’4A Guide to the Project Management Body of Knowledge (PMBOK* 
Guide). This important reference has gone through a transformation in the past few years and here we take a closer look at 
the current PMBOK" Guide. 
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l 6 Tips for Passing the 
PMP® Exam the First Time 


Introduction 


This chapter serves as a review of some of the key things you need to understand as you prepare for the 
exam. Now that you’ve studied each topic individually, let’s put your knowledge and understanding all 
together. Ritas Process Chartafid Rita’s Agile Process Chart can help you connect the concepts 
found in this book. By now, you should understand the overall project management process, including 
all the efforts involved in it. You should also know the commonly occurring terms and concepts cov- 
ered in the “Foundations” chapter. Understanding these terms and concepts will help you understand 
how each of these things relate to the overall project management process. 

As you work through this chapter, take this as an opportunity to find remaining gaps in your 
knowledge so you can review content related to your gaps and are prepared to pass the exam on your 
first try. 


Review of Core Concepts 


Over the next several pages, we review some of the frequently occurring terms and concepts you need 
to understand for the exam. This section reviews planning, working, and delivery concepts and arti- 
facts. There is also a section on formulas and calculations, tips for preparing for the exam itself and for 
the exam environment, common project management errors and pitfalls, and several exercises to give 
you more interaction with the material. 


Planning, Working, Measuring, and Delivering 

Planning is a key step in addressing the areas of requirements and scope, schedule, cost, quality, 
resource, communications, risk, procurement, and stakeholders, as well as plans for configuration 
management (or artifact version control), and change management. It is a crucial part of a project 
manager s job in a predictive environment. 

These areas of planning occur within agile and hybrid environments but may be less formal or 
take different forms. Planning addresses the majority of questions and concerns that might come up 
throughout the life of a project, and it allows the project manager and team to spend more of their time 
completing the work of the project and less time dealing with issues and problems. 
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Review some of the forms that planning and artifacts take in predictive and adaptive environments: 


Predictive Environment Plans and Artifacts 


Project management plan (a plan for 
scope, schedule, cost, quality and 
other constraints as well as other 
important project management 
aspects like communications and 
stakeholder relationships) 


Assumption log, change and issue 
logs, stakeholder and risk registers, 
lessons learned 


Project life cycle and development 
approach, tailored to the project 


Requirements documentation 


Scope, schedule, and cost baselines 
(the performance measurement 
baseline—part of the project 
management plan) 


Reporting templates and reports: 
Risk reports, EVM (earned value 
measurement), forecasts, quality 
reports 

Project and team charters 
Procurement statement(s) of work 
Agreements and contracts 

Quality control metrics 


Assumptions and constraints analysis 
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Adaptive Environment Plans and Artifacts 


Release map, release plan, iteration 
plan, product roadmap 


Product and project backlogs 
(risk-adjusted backlog) 


Features, stories, definition of done 
Personas 


Meetings: Release planning, iteration 
planning, iteration review, iteration 
retrospective 


Information radiators: e.g., product 
roadmap, Kanban board 


Value stream mapping 


Burnup charts, burndown charts, 
team velocity 


Reprioritizing the backlog 
Negotiating change; expecting 
frequent change 


Negotiating scope while keeping 
schedule and cost fixed 
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16.1 Exercise 


Tips for Passing the PMP® Exam the First Time 


Here is a way to get more familiar with the project management processes from the Process Groups model 
perspective. In your Exercise Notebook, draw a chart with a header as shown here. For each process listed, fill in the 


appropriate information in each column. Do not worry if you do not get it perfectly correct. It is in the practice that 


you will be better at understanding these components on their own, and holistically. 


Project Management Process 


Define Activities 

Plan Procurement Management 
Monitor and Control Project Work 
Sequence Activities 

Collect Requirements 

Direct and Manage Project Work 
Develop Project Management Plan 
Develop Schedule 

Validate Scope 

Perform Qualitative Risk Analysis 
Identify Stakeholders 

Conduct Procurements 

Define Scope 


Perform Integrated Change Control 


Answer 


What Does It What Process What Process 
Process Group Include? Comes Before? Comes After? 


The answers to this exercise provide a description and the associated actions to the given process. These descriptions 


align with the required interpersonal skills as well as the project management and technical activity needed. 


Project 
Management Process 


Process Group What Does It Include? 


What Process What Process Comes 
Comes Before? After? 


Define Planning Creating an activity list from each Plan Schedule Sequence Activities 
Activities work package Management 

Plan Planning Creating the procurement statements None Conduct Procurements 
Procurement of work, bid documents, and the 

Management procurement management plan 

Monitor and Monitoring Measuring and analyzing Manage Project Perform Integrated 
Control and performance against the project Knowledge Change Control 
Project Work controlling management plan and baselines 
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Sequence 
Activities 


Collect 
Requirements 


Direct and 
Manage 
Project Work 


Develop 
Project 
Management 
Plan 


Develop 
Schedule 


Validate Scope 


Perform 
Qualitative 
Risk Analysis 


Identify 
Stakeholders 


Conduct 
Procurements 


Define Scope 


Perform 
Integrated 
Change 
Control 


Planning 


Planning 


Executing 


Planning 


Planning 


Monitoring 
and 
controlling 


Planning 


Initiating 


Executing 


Planning 


Monitoring 
and 
controlling 


Creating a network diagram 


Documenting detailed requirements 
and creating the requirements 
traceability matrix 


Facilitating and producing work 
according to the project management 
plan 


Integrating all the individual 
management plans and baselines, and 
creating a project management plan 
that is bought into, approved, 
realistic, and formal 


Creating a bought into, approved, 
realistic, and formal schedule and 
schedule baseline 


Meeting with the customer to gain 
formal acceptance of interim deliverables 


Analyzing the probability and impact of 
potential risks to determine which risks 
might warrant a response or further 
analysis 


Identifying, documenting, and analyzing 
information about stakeholders on the 
project 


Selecting a seller and obtaining a signed 
contract 


Creating the project scope statement 


Evaluating the impact of requested 
changes to the project and approving or 
rejecting change requests 
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Define 
Activities 


Plan Scope 
Management 


Develop 
Project 
Management 
Plan 


Develop 
Project Charter 


Estimate 
Activity 
Durations 


Create WBS 


Identify Risks 


None 


Plan 
Procurement 
Management 


Collect 
Requirements 


Monitor and 
Control Project 
Work 


Estimate Activity 
Durations 


Define Scope 


Manage Project 
Knowledge 


Direct and Manage 
Project Work 


Control Schedule 


Control Scope 


Perform Quantitative Risk 
Analysis (don’t forget, 
however, that some 
projects, or individual 
project risks, may skip this 
process and go straight to 
Plan Risk Responses) 


Plan Stakeholder 


Engagement 


Control Procurements 


Create WBS 


Close Project or Phase 
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16.2 Exercise 

If you found this exercise helpful, you may want to continue to test yourself on other processes not listed here, and 
review your answers against the process descriptions in this book. In this exercise for plan-driven projects, read 
each scenario and write down what process you are in when you are doing the activity. 


Scenario 


= Soemrnnnpwn wv 


. When meeting with the customer to obtain acceptance of interim deliverables 

. When measuring project performance against the performance measurement baseline 
. When making sure people are using the correct processes 

. When evaluating whether performance reports are meeting stakeholders’ needs 

. When working with the project team 


When assessing stakeholder relationships 


When you notice that there are many unidentified risks occurring 


. When evaluating a seller’s performance 

. When evaluating team members’ performance 

. When making sure deliverables meet quality standards 

. When communicating with stakeholders to resolve issues and manage their perceptions about the project 


Answer 


Processes Being Described (on Plan-driven projects) 


Se e 


. Validate Scope 

. Control Scope, Control Schedule, Control Costs 
. Manage Quality 

. Monitor Communications 


Manage Team 


. Monitor Stakeholder Engagement 
. Monitor Risks 

. Control Procurements 

. Manage Team 

. Control Quality 

. Manage Stakeholder Engagement 
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16.3 Exercise 
Now let’s switch it up for agile. For agile projects, read each scenario and write down what activity you are engaged 
in for the given scenario, or what tools or methods you would use to perform the activity. A variety of activities may 


fit the description for any one scenario. 


Scenario 


AUN 


HFSS wn an 


. When meeting with the customer to obtain acceptance of interim deliverables (from the iteration) 
. When performance is measured against the performance metrics 

. When making sure people are using the correct processes and how do they do it 

. When and where teams evaluate whether project performance is meeting stakeholders’ needs 
When working with the project team; helping the team 

When assessing and ensuring good stakeholder relationships 

. When there are unidentified risks occurring (What to do?) 

When evaluating a seller’s performance 

. When evaluating and helping improve team members’ performance 

. When making sure deliverables meet quality standards 


. When communicating with stakeholders to resolve issues and manage their perceptions about the project 


Answer 


Processes Being Described (on Plan-driven projects) 


1; 


2 


Product owner works with stakeholders to prioritize backlog items; iteration (or Sprint) review meeting 


. Average team velocity, burnup charts, burndown charts; retrospectives where team reflects on their 


own performance 


. The project manager (agile coach, team lead, Scrum Master) uses servant leadership to help the self- 


organized team to refine and follow their agreed-upon processes 


. Iteration review (Sprint review); communication on a daily basis with the product owner (customer); 


retrospective; face-to-face communication 


5. Servant leadership; ensure teams are adequately trained; remove impediments 


. Face-to-face and other communication methods; product owner (customer representative) as integral 


team member; continuous delivery of value; iteration review meeting 


. Re-evaluate risk frequently; reprioritize the risk-adjusted backlog 


. Agile contract; control procurements; iteration reviews 


9. Servant leadership; ensure adequate training; remove impediments; team retrospectives 


It. 


Team organizes their own work; team controls quality, works with product owner; team checks their own 
work; avoid errors and ensure better design through paired programming 


Working with product owner to assure stakeholder priorities are considered; ensure a common 
understanding; manage stakeholder engagement 


400 


SIXTEEN Tips for Passing the PMP® Exam the First Time 


The Significance of Quantitative Measures on the Exam 


Hie exam will not include a lot of questions requiring you to perform calculations. However, it is important to understand 
the contexts in which formulas are used in project management. 


Think About It. There are few formula questions on the exam. You must choose whether or not to memorize all 
> or some of these formulas for the few exam questions you may see that use calculations. Regardless, you should 
a use figure 16.1 to review the chapters in this book in which the formulas appear. Knowing the contexts in which 
the formulas are used will help you get questions right. For instance, even if you are not asked to calculate SPI 
(schedule performance index) or CPI (cost performance index), or to calculate EMV (expected monetary value 

of a risk), you should know the answer. Here are two example questions to try. 


Example 1 The project manager is working for a pharmaceuticals company that is very cost conscious and is only slightly 
more flexible on schedule. The project manager prepares a monthly report and notices that the SPI is 1.3 and the CPI is .89. 
What should the project manager do? 

Even before you look at the answer choices, you should know what these numbers mean for the project. Here is a 
possible multiple-choice answer set: 

A. Prepare options for getting the schedule in control. 

B. Nothing; schedule and cost are both under control. 

C. Prepare options for getting the schedule and cost in control. 


D. Prepare options for getting cost in control. 


Example 2 The project manager and team are analyzing new risks on a multimillion-dollar construction project. There are 
no safety issues involved. Which risk has the highest priority? Risk Z is that a supply item will be late, has an EMV of 
$4500, and the least expensive contingency plan will cost $4600. Risk X is that an activity along the critical path may finish 
early and the EMV for it is $38,000. Risk Y is that an activity will be late, has an EMV of $770, and the least expensive 
response will cost $650. Risk W is that an activity will finish early, the EMV is $2200 and it is not along the critical path. 


A. Risks Z and X have equal priority 
B. Risk W has the highest priority 
C. Risk X has the highest priority 
D. Risk Z has the highest priority 


Answers: 


Examplel The answer is D. Explanation: For an SPI or a CPI, you should know that greater than one is good and less 
than one is bad. So you can see from these numbers that we are ahead of schedule (1.3 is greater than one) but over budget 
(.89 is less than one). This fact eliminates the other options. 


Example2 The answer is C. Explanation: If we can finish an activity early along the critical path and save $38,000, we 
should prioritize this contingency plan. Why? Risk Z has a least expensive contingency option with a slightly greater cost 
than the EMV if the risk were to occur. We can leave that contingency plan in place but there’s not much more we can do 
there. Risk Y would not be a priority on a multimillion-dollar project, especially with so little difference between EMV of 
the risk and the contingency plan cost. Risk W would be good to do if we could save $2000, but it is not worth much 
savings and is not along the critical path so would not have the highest priority. 
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AC + (BAC - EV) 
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Formulas to Understand for the Exam 
PMP® Exam Prep 
Name Formula Chapter Reference 
FV Project Management 
Present value (PV) = : 
(+nr)" Foundations 
Expected activity duration (triangular P+M+O Schedule 
distribution)* 3 
E Pen men 
pected acuity duration P+4M+0O Schedule 
(beta distribution)* 6 
Total float LS-ES orLF-EF Schedule 
Cost variance (CV) EV-AC Budget and Resources 
Schedule variance (SV) EV-PV Budget and Resources 
EV 
Cost performance index (CPI) “AC” Budget and Resources 
s EV 
Schedule performance index (SPI) PV Budget and Resources 


Budget and Resources 


Budget and Resources 


Budget and Resources 


p ; y., (BAC-EV) 

Estimate at completion (EAC) = m ~ Budget and Resources 
(CPI? x SPIC) 
To-complete performance index (BAC - EV) 
—— Budget and Resources 
(TCPI) (BAC-AC) 
Estimate to complete (ETC) EAC - AC Budget and Resources 
Variance at completion (VAC) BAC - EAC Budget and Resources 
PRESS n(n-l) or 
Communication channels as Communications 
2 

Expected monetary value Pxl Riksa is 
(EMV—Cost) 
Expected value (EV—Schedule) Pxl Risks and Issues 


Remember that these formulas can be used for costs as well as activity durations. 


FIGURE 16.1 Formulas that may appear on the exam 


If you decide you want additional practice with earned value measurement (EVM) concepts and formulas, 
return to the Earned Value Management section of the “Budget and Resources” chapter. You could do the 
Fence exercise again to help you feel more comfortable with the concepts. Also remember that we have 
additional exercise on EVM as well as on other topics, on the RMC Resources page. 


RMC RESOURCES 
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More Tips for Exam Preparation 


Many people fail the exam because they do not properly prepare. You can avoid that mistake. Read the following tips slow- 
ly, and honestly assess how each item applies to you: 

o Know the material thoroughly, but do not approach the exam assuming it tests facts that you must memorize. The 
exam also tests application and analysis. Be prepared to apply the concepts and methods in a variety of scenarios, 
including how they work in combination with each other. 

o Have real-world experience using the major project management methods. Try to gain experience with methods 
with which you have gaps. Where gaps remain in your experience (we all have them), practice making the methods a 
reality for you by applying them and creating the associated artifacts using a case study from your job or the library 
case study used in this book. 

o Make sure you can quickly visualize how tools and processes would be used on a project. Practice visualization 
especially with tools and methods you were most unfamiliar with when you started this course of study. This 
visualization will help you prepare for situational questions on the exam. 

o When answering predictive questions on the exam, think in terms of large projects. This will help you remember the 
importance of processes and methods that you may not be using in your real-world project management. It is easier 
to scale down than to scale up. 

o When answering adaptive questions on the exam, remember that scope is evolving as project work takes place and 
that change is common. 

o When answering hybrid questions on the exam, look for clues as to whether the specific answer requires methods 
from an adaptive or predictive approach. Hybrid projects use both. 

o Understand the areas that PMI emphasizes (PMI-isms, explained in chapter | and in the “Quality of Deliverables 
and Products” chapter). 

a Be familiar with the types of questions you can expect on the exam, but do not be alarmed if you see new types of 
questions when you take the exam. 


o Be prepared to see situations on the exam that may be ambiguous or wordy. Practice interpreting these types of 
questions using RMC Chapter Quizzes or FASTrack" (if you have it). Practice using analysis to select the best 
answer from what appears to be two or more “right” answers. 

a Deal with stress before you take the exam. If you are a nervous test taker, using PM FASTrack* can give you an 
opportunity to practice stress control. 

o Plan and use a strategy for taking the exam. This may mean you will take a mental break after every 50 questions, or 
that you will answer all exam questions as quickly as possible and then take a break before you review, and 
potentially adjust, your answers. 

o Expect that there will be questions you cannot answer or even understand. This happens to everyone. Be prepared 
so you do not get anxious or doubt your abilities during the exam. 

o Ifyou go to an exam testing site, do not expect it to be quiet. Use FASTrack® to practice answering questions in an 
environment that is not 100 percent quiet. 


o Ifyou take an online proctored exam, make sure you have a testing area that is free of interruptions (including pets). 
Set up your space so that it is comfortable, but make sure you carefully read the instructions PMI sends regarding 
taking the online exam. Don’t let taking the exam in your home or office become an additional stressor. 

o Do not overstudy. You cannot get an A on this exam. Getting completely comfortable with all the material in this 
book is just not possible. It is not worth studying for hundreds of hours. It is a waste of time and will not guarantee 
you'll pass the exam. 

o Do not study the night before you are scheduled to take the exam. Instead, do something relaxing and get extra 
sleep. You want to be fresh and well rested. 
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Preparing for the Exam Environment 


This book has presented what you should do and know before you take the exam. Now, let’s prepare you for the big day. The 
following are some tips for taking—and passing—the exam (at a testing center). 

1. You must bring your authorization email from PMI to the test site, as well as two forms of ID with exactly the 
same name you entered on the exam application. 

2. Make sure you are comfortable during the exam. Wear layered clothing so you can remove outer layers if you 
become too warm. (Note, however, that you may encounter specific requirements regarding removed clothing 
while taking the exam.) 

3. Have something to eat or drink available in case you need either during the exam. You will not be able to access 
these items while taking the exam but you will be able to take a break, and you may be thirsty or hungry and you'll 
want to get rid of that distraction. 

4. You will be given something on which to make notes during the exam. This may be something physical, such as 
paper and a pencil or a small white board, or it maybe electronic. (Note: If you are taking the online exam, you will 
not be allowed to have a physical white board or paper and pencil. You will have access to the electronic white 
board.) 

5. After you start your exam, consider taking no more than five to seven minutes of your test time to create your 


“download sheet,” which is where you write down anything you have trouble remembering. It will free up your 
mind to handle exam questions once the information you are most concerned about is written down. 

6. You will likely have one or two technology and/or computer tutorials (general testing tutorial and PMP test- 
specific) to complete prior to the start of the exam. This will help you become familiar with the computer-based 
test functionality. You need to start and complete those tutorials within their allotted time. Then you can start your 
four-hour exam. 

7. You will have access to a calculator during the exam. The computer will have a calculator function and the tutorial 
will show you how to use it. 


8. The exam does not adapt to your answers. This means 180 questions are selected when your exam starts, and 
those 180 questions will not change. 

9. Use deep-breathing techniques to help you relax and focus. This is particularly helpful if you are very nervous 
before or during the exam and when you notice yourself reading the same question two or three times. Breathing 
techniques can be as simple as breathing deeply five times, to provide more oxygen to your brain. Many people also 
find it helpful to close their eyes when they do this. 

10. Smile when taking the exam. This may sound hard to do when you are stressed and taking an exam for four hours, 
but studies show that smiling relieves stress and makes you feel more confident. 

11. Use all the exam time. Do not submit your exam early unless you have reviewed every question you skipped or 
marked for review. 
12. Everyone has their own unique test-taking quirks and style. When you work through the exam simulation in PM 
FASTrack*, pay attention to your quirks. You may have to create a plan to work through any that may negatively 
impact you while taking the exam. 
13. Control the exam; do not let it control you. How would you feel if you read the first question and didn’t know 
the answer? And then the same thing happened after you read the second and third questions as well? This may 
happen because your level of stress is not allowing you to think. So what do you do? If you do not immediately 


know the answer to a question, leave it blank, or use the Mark for Review function and come back to it later. 

14. Control frustration and maintain focus on each question. You might dislike or disagree with some of the 
questions on this exam. You might also be surprised at how many questions you mark for review. Make sure you 
stay focused on the current question. If you are still thinking about question 20 when you reach question 120, 
there will have been 100 questions not given your full attention. 
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15. Answer each question using your knowledge of project management good practices. Be prepared to separate 
your experience from PMI’s perspective (which often matches “textbook” practices more than real-life). Many 
people who fail the exam try to answer questions from their real-world experience. Your experience will help you 
but don’t forget to rely on your training. 


16. First, identify the actual question in the words provided (it is often the last sentence), and then read the rest of 
the text. Note the topics discussed in the question and in the descriptors. This should help you understand what 
the question is asking. 


17. Carefully consider each answer choice listed and choose the best one of the choices given. Don’t read too much 
into the answers. We often make mistakes when we make automatic assumptions because as adults our experience 
leads to assumptions. Take the questions and answer choices literally. 


18. Do not make this mistake. One common reason people answer questions incorrectly is they do not read all four 
answer choices. Make sure you read each question and all four choices. This will help you select the best answer. 
If you find yourself forgetting to read all answer options, start reading the choices backwards (choice D first, then 
C, etc.). 


19. There may be more than one seemingly correct answer to each question. But there will only be one “best” 
answer. Make sure you are looking for the best answer. 


20. There will be answer choices that are meant to distract you from the correct answer. They present more than one 
plausible choice. Such choices make it appear as though some questions have two or more right answers. It often 
seems there are only shades of difference between the choices. As noted earlier, make sure you look for the best 


answer, and think about the situation in terms of project management good practices. 


21. Be aware that questions may also include irrelevant information. 


22. Look for words and phrases such as “still,” “yet,” “first,” “last,” “next,” “except,” “not,” “most likely,” “less likely,” 
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“primary,” “initial,” and “most.” Make certain you clearly read the question and take note of these words so you 
will answer the question correctly. 


23. Watch for choices that are true statements but do not answer the question. 


24. Watch for choices that contain common project management errors. They are intentionally there to determine 
ifyou really know project management. You can combat this by looking for errors in your knowledge and correcting 
those errors as you go through this book and work with RMC Chapter Quizzes and/or FASTrack*. (See the 
“Common Project Management Errors and Pitfalls” section in this chapter.) 


25. Options that represent broad, sweeping generalizations tend to be incorrect, so be alert for words such as 


” e 


“always,” “never,” “must,” “completely,” “all? and so forth. Alternatively, choices that represent carefully qualified 


3 ee, D 66 33 ee, 


statements tend to be correct, so be alert for words such as “often,” “sometimes,” “perhaps,” “may,” and “generally.” 
26. You may see some poorly worded or grammatically incorrect questions or answer choices on the exam; don’t let 


this distract you. 


27. Look for answers that support the value of project management and that proper project management has 


been done unless evidence in the question tells you otherwise. 


The exam will not be scored until you indicate you are ready, or after four hours have passed. You will also be asked if 
you are certain you want to score your exam after you submit it. You will receive a summary of your test results. If you do 
not pass, PM1 will send you information on retaking the exam. You will have to pay an additional fee to retake the exam. 
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TRICKS Are you ready for some very important tricks to keep in mind when you take the exam? Pay careful attention: 


+ Recognize that “rules” (what we think should be best) are meant to be broken. Rules, such as what to do 
when there is a conflict, can change depending on the situation. This drives some people crazy—especially 
those who expect the exam to just test facts. You need to be able to read and understand the situations on 
the exam and then be able to figure out the best thing to do in that situation. 

e Unless stated otherwise, assume proper project management was done. If you answer a question thinking 
about real-world projects that do not use proper project management, you might miss the correct answer. If 
the question makes it clear that proper project management has not been done, you'll likely need to think 
about what is missing, how to solve the root cause of the problem, and how to make sure proper project 
management is carried out going forward on the project. 

+ For each question notice which part of the project the scenario is occurring in. If the situation described is 
taking place in planning, your answer may be different than if it was occurring during executing. 

+ Be prepared for questions with multiple problems. A question may describe a situation with various 
problems and ask you to determine which one to address first. Here is an example: 

Two stakeholders are disagreeing via a series of emails as to whether a deliverable meets the acceptance criteria. The 
cost-benefit analysis done in planning did not support delivering a higher level of performance, and the stakeholders 

agreed. A team member has just informed you that a problem with his work has occurred. The deliverable he is 

working on must be shipped today or there will be a project breach. One of the stakeholders having the email 

disagreement comes to you to complain about the other. What should you do? 


The following tips will help you focus on the most important problem in order to select the best answer. It is important 
to note that all these tips will not apply all the time, and they do not have an order of importance. 


+ Determine the immediate problem to address. 

+ Deal with the root cause first. 

+ Deal with the problem with the greatest negative impact first. 
* Solve the problem that occurred the earliest. 


+ Look for a proactive solution. 


Common Project Management Errors and Pitfalls 


As mentioned at other points in this book, the exam often includes common errors in project management as possible an- 
swers. Read the following summary of some of the major errors even highly experienced project managers make, and make 
sure you understand why these are errors. 

Common project management errors include the following: 

+ Focusing primarily for activity status on percent complete 

+ Holding “go around the room” status meetings 

+ Spending most of your time micromanaging team members by constantly checking on them 

+ Asking team members to cut 10 percent off their estimates 

* Thinking a bar (Gantt) chart from scheduling software is a project management plan 

+ Not attempting to obtain finalized requirements 

+ Not getting real resource commitments 

+ Not having a rewards and recognition system 

* Not focusing on quality 

+ Not having a change control system 


+ Not having management plans (in a predictive environment) 
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+ Not measuring against the project management plan (in a predictive environment) 

+ Not creating metrics to measure and evaluate performance 

+ Not spending time finding and eliminating root causes of problems or deviations 

+ Not implementing corrective actions to keep the project in line with the project management plan 

+ Not reevaluating the effectiveness of the project management plan 

+ Not reevaluating the accuracy or completeness of scope, schedule, or cost 

+ Not keeping the project management plan and project documents updated to reflect changes and revised information 
about the project 

+ Ignoring resource managers’ responsibilities to manage ongoing business operations in addition to responding to 
project needs (team and physical resources) 

+ Not realizing the project can affect the reputation of team members 

+ Not realizing the project manager has resource responsibilities; these can include responsibilities to the project team 
(such as creating project job descriptions, evaluating individual and team performance on the project, and adding 
letters of recommendation to team members’ human resource files) as well as responsibilities related to 
physical resources 

+ Blaming unrealistic schedules on management instead of realizing that developing a realistic schedule is the project 
manager $ responsibility 


A Day-in-the-Life 


The following exercise provides one last opportunity to test yourself to see if you really understand what a project manager 
does. 


16.4 Exercise 

Many people do not practice the breadth of project management practices described in the ECO and other PMI 
references on their real-world projects. This exercise is designed to help you uncover what you might be doing that 
represent differences between your real-world experience and project management practices from the 
PMI perspective. 


In your Exercise Notebook, list which activities a project manager should spend the most time doing, on average 
during a typical day, and what they should spend the least amount of time doing. This would be after planning is 
complete (to the degree needed for the current phase, iteration, etc.) and the team is working on building 
the product. 
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Answer 


SIXTEEN 


There are a number of ways this question can be answered correctly. Let’s review some of the items that should not 
be taking up most of your time, and what should typically be included during the course of a day. Think through 
the items listed here and identify whether you have any misconceptions about what you should be doing as a 
project manager. If you do, clarify and fix these misconceptions before you take the exam. 


How you should NOT be spending most of your time What should typically be included in your day 


Dealing with problems and unexpected changes 
(rather than preventing them and having risk 
contingency plans) 


Schedule and other items related to 
schedule management 


Meetings 


- Micromanaging 


Completing work activities 


Dealing with problems that arise from 
unhappy stakeholders 


Clearing up communications issues 


Managing team member conflict that they could 
manage on their own 


Using artifacts like a WBS or product backlog, and a 
project management plan 


Measuring and evaluating 
Being of service to the team 
Removing impediments to team progress 


Recommending and taking corrective and preven- 
tive actions 


Implementing risk responses or communicating 
with risk owners about them 


Coaching, mentoring, and team building 


Continually communicating the vision with the 
team and stakeholders 


Communicating and using active listening 
Managing by exception to the plan 


Interacting with stakeholders to maintain and 
improve stakeholder engagement 


Looking for possible changes 
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Introduction 


We have discussed agile practices throughout this book. In this chapter, we will look closer at the foun- 
dation for agile through the Agile Manifesto and examine some of the different methodologies. These 
methodologies include: 


+ Lean * DSDM (Dynamic Systems 

* Kanban Development Method 

+ Scrum * FDD (Feature Driven Development) 
+ XP (extreme Programming) + SAFe* (Scaled Agile Framework) 


e Crystal Family of Methodologies 


Although agile seems new to many people, it actually has been around a long time, and the ideas 
used by agile practices are certainly not new. What we call “agile” is a compilation of practices people 
have experimented with and then taken what has worked. This collection of good practices has 
become systematic. 

Practitioners often use the terms agile and adaptive interchangeably. In reality, agile is a practice 
and adaptive is a more general term. To review, in adaptive environments scope cannot sufficiently be 
defined at the beginning of a project and will remain largely unstable throughout the project. Scope 
is emerging. 

Before continuing, review the following sections of the “PMPX Exam References in 
Context” chapter: 

+ Agile Process Overview 

°  Rita’s Agile Process Chart " Game You should have played this game once when you first read 

that chapter. It is a good time to play this game again for review. 


Overview 


Following are the common agile methodologies that have given agile practitioners a set of practices to 
combine and customize, depending on the needs of the organization, its products and projects, its 
teams, and its stakeholders. We discuss Lean and Kanban first since they are not agile methodologies. 
Instead, both Lean and Kanban are independent methodologies (originally related to manufacturing) 
from which agile has integrated many ideas. 

As you read you will also find a bias toward software development. This is because it was among 
software developers that various methodologies were synthesized and the agile philosophy was 
organized and spread. If you are not in the software development field, think about how these methods 
can be applied in your organization. As we have mentioned before in this book, agile methods are now 
used with a variety of projects that are a good fit for an adaptive development approach. 

The last sections of this chapter describe the common agile influences and agile philosophy, also 
known as agile’s four values and twelve principles (found at agilemanifesto.org). 
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Lean 


Lean product development is an approach that has its history in manufacturing but has been adapted over time to many 
areas of business, including agile project management. For the exam know that agile methods ascribe to Lean principles. 
Here are the fundamentals of Lean’s seven principles: 
¢ Eliminate waste Examples of waste in product development include wait time (and motion, or the time required to 
take action), incomplete work, extra processes or features, task switching, and defects. A helpful Lean tool for 
eliminating waste concerns the value chain and value stream mapping. As discussed in the “Complaince and Delivering 
Value” chapter, value stream mapping maps out and analyzes all steps in a product (build and) delivery process to see 
where the team can eliminate waste. 


¢ Amplify learning Examples of this Lean principle show up in agile’s constant feedback loop facilitated by iterative 
planning (e.g., product visioning, release and iteration planning). The daily standup meeting, iteration reviews, and 
retrospectives are additional examples of built-in opportunities to amplify learning. 

* Decide as late as possible Since in adaptive environments so much information is not available at the beginning of 
a project, agile teams make decisions about each next stage or each next iteration (or sprint). However, in contrast to 
predictive environments where there is “big planning up front” and many decisions are made early, agile teams defer 
decisions about anything beyond the next stage (be it the release plan, the iteration plan, etc.) to the “last responsible 
moment.” 


¢ Deliver as fast as possible The iterative and incremental delivery of agile means that teams are delivering value 
continually and as quickly as possible. This is a Lean concept and all agile methodologies use it. 
Example While doing value stream mapping, if the team uncovers a process that is no longer needed, it can be 
eliminated immediately. 
+ Empower the team Built into agile—and into the ECO—are the principles of using people skills, trusting in team 
members’ skills, providing training where needed, and trusting the team to make the decisions about their own work. 
Examples A belief in employee self-determination and an understanding ofhow motivation enables good servant 
leadership for empowering the team. 


¢ Build integrity in This refers to product integrity, which includes not only a product that works well for its intended 
use but is also easily usable by the customer. 

Example Agile teams use personas to make customers real people in their minds. For example, if they are building 
an online movie rental site, personas allow them to ask: “Is this going to be quick and easy for ‘Harried Henry’ to use?” 
These kinds of questions can lead the team to remove suboptimal usability factors from the product, streamlining it 
for the end user. 

* See the whole Do you remember when we discussed systems thinking? Look to the “Compliance and Delivering 
Value” chapter to review this information as needed. Think about a product as a system with interacting parts that are 
also interdependent. You must think holistically about the product, and agile teams are encouraged to do this with this 
principle, as with others related to systems thinking. 


Koa Think about it. Do you ever find yourself doing something while thinking “This is a waste of my time”? Do you 
QO . think about how you could streamline the process or eliminate it? If so, you are thinking Lean. 
a 
Kanban 


Derived from Lean, Kanban is a Japanese word meaning “signboard” (think sidewalk signs outside cafes advertising the 
daily specials). There are two things you need to know about Kanban for the exam. First, a Kanban board is an information 
radiator, or highly visible and graphic display of project information. In agile, Kanban boards were meant to be low-tech and 
high-touch. They were created with sticky notes on white boards or flip charts. Now, there are many electronic tools that 
allow teams to share Kanban boards collaboratively from dispersed locations. 
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In the Communications chapter, we showed the following example of a Kanban board: 


Story Ready Task Ready Task In Process Task Done Story Done 


FIGURE 17.1 Kanban board 


The second thing to know about Kanban for the exam is that there are five core principles. Looking at figure 17.1, can 
you see how the Kanban board supports the first three principles listed below? 

Kanbans five core principles are: 

e Visualize the workflow The team and any other project stakeholder can see the status of tasks in progress, at 
any time. 

+ Limit WIP (work in progress) Iteration backlogs are an example of limiting work in progress. On a Kanban board, 
tasks are coded or colored for the person responsible for completing them. In the example given in figure 17.1, a new 
task will not be added to the Task in Process column for a team member until their current task moves to the Task 


Done column. 
* Manage flow By doing the first two principles and by focusing on the unfinished task before another task is added, 


the project manager is managing flow. 


* Make process policies explicit The entire team must know the entire product and process at least at a high-level 
and not just the component they are building. This way they can understand their own contribution holistically and 
practice systems thinking. 

+ Improve collaboratively Collaborative work and continuous improvement are critical for agile teams. Improving 
collaboration is encouraged in Kanban and facilitated by the Kanban board as an information radiator that is discussed 


regularly among the team. 


Think About It. Look again at the Kanban board example in figure 17.1. Can you see why Kanban, if used as a 
- product development method, is called a pull system? 


a + A team member pulls a task from Task in Process and moves it into Task Done when it is completed. 
+ Only then will they pull a task from the Task Ready column and move it into Task in Process. 
+ Limiting how many stories (which are broken into tasks) go into the Story Ready column helps control flow 
and limits work in progress. 
+ This distinguishes Kanban from other agile methods that use iteration cycles to control work in progress. 

Note: Jmportantly, there is a difference between agile methodologies that use Kanban ideas and Kanban as a 
methodology. Kanban is a distinct methodology and can be used to manage a project. Kanban as a methodology 
doesn’t require iterations. However, Kanban boards (i.e., signboards) are used in many agile methodologies that are not 
using the previously described pull system. Kanban boards are often, in fact, used in combination with iteration cycles. 


All 


Common Agile Methodologies 


Scrum 


SEVENTEEN 


Scrum started with software developers and has the distinction of being the most well-known and popular agile methodol- 
ogy, and is therefore the most influential for many agile teams. Many people use agile and Scrum terms interchangeably. In 
fact, on the exam, in agile and hybrid questions, you are likely to sometimes see Scrum terms used interchangeably with 


so-called generic agile terms. For example, many people recognize “iteration” as a generic agile term (even though it came 
from XP) but if they hear the term “sprint” they think specifically of Scrum. The terms mean the same thing—a time-boxed 
period of building the product—and are used similarly and often interchangeably. 


Scrum and Agile Generic Terms 


The below table shows the 


generic agile terminology and its Scrum equivalent: 


Category Scrum Term Generic Agile Term 
Activities * Sprint * Iteration 
* Sprint planning + Iteration planning 
e Daily scrum (ceremony) * Daily standup (meeting) 
* Sprint review (ceremony) * Iteration review (meeting) 
+ Sprint retrospective (ceremony) + Iteration retrospective (meeting) 
* Backlog refinement + Backlog prioritization 
Team Roles * Product owner * Product owner (or customer) 
* Scrum Master + Agile coach, team lead 
+ Development team + Development team 
Artifacts + Product backlog + Product (or project) backlog 
+ Sprint backlog e Iteration backlog 
+ Potentially shippable product + Minimally viable product (MVP) 
(increment) (increment) 


Note the following about 


+ You can see from the number o 


the terms in the table above: 


analogous terms here that generic agile has borrowed a lot of practices, like the 


concept of the backlog, from Scrum. 


* Generic agile teams may adhere to a custom mixture of these practices, depending upon organizational and PMO 


governance. Organizations using a generic form of agile may have a customized approach to team training. 


e Organizations that have implemented Scrum adhere more strictly to specific Scrum practices and Scrum teams. 


Scrum teams are like! 
the organization. 


ly to have to be trained specifically in Scrum by certified Scrum trainers contracted from outside 


+ There are several different backlogs, be careful when reading exam questions. 


«J The product backlog represents all the known product scope. Features are continuously added and removed 


as the customer mal 


es decisions about product scope. 


*/ A project backlog—if the term is used—refers to all the known product scope that will be built during a 


particular project. 


/ The terms product 


backlog and project backlog are not mutually exclusive, and many teams just use the term 


product backlog. We include the term project backlog in case you encounter it on the exam. 


¢/ The sprint (or iteration) backlog is the specific increment or increments of product that are currently at the 
top of the prioritized backlog and are selected for the next (or current) sprint. You may recall from earlier in 
this book that a project consists of a series of sprints (or iterations) leading up to one or more product releases. 
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+ The product backlog is a perpetual artifact as long as the products life’cycle continues. 
>/ For new product development the backlog contains the features needed for at least the first product release. 
It may include enough features for more than one product release in a single project. The scope of a single 
project (including how many releases) is as always defined and negotiated with the customer or key internal 
stakeholders (represented by the product owner), depending on the resources available for the project. 


</ For ongoing development on an existing product, the backlog is a combination of new features, fixes for 
defects (bug fixes, for software), and upgrades to existing features. 


Think About It. Scrum and generic agile terms are commonly used interchangeably in exam questions, so do 
not be distracted by semantics while taking the exam. If you are well prepared, you will understand a particular 
a question from the context of the given scenario. 


Scrum Core Concepts 
The following are considered to be Scrum core concepts: 


¢ Iterative and incremental development Scrum practitioners deliver increments of the product, which they build 
in sprints. 


Dedicated team The Scrum team is dedicated to the project and it is stable, meaning the same people stay on the 
team and projects are brought to them. This contrasts with predictive environments where different teams may be 
assembled and broken up on a per-project basis. 


Cross-functional team Scrum team members are “jacks of all trades, masters of a few.” This means that in contrast 
to traditional teams where members are specialists in a field or two, a Scrum team member can fill in for another team 
member as needed. For example, a computer programmer may also do testing. 


Pillars The pillars are essential Scrum core concepts. They are transparency, inspection, and adaptation. 

y Transparency This means creating a common understanding among all responsible parties. Creating a 
project or product vision, a team charter, and a definition of done for a story or a product increment are all 
examples of transparency. 

y Inspection This is about examination of how the work is going on a regular basis, assessing how the team is 
progressing, and what may need to change to continuously improve alignment of team performance and 
project (or product, or iteration) goals. 


y Adaptation This is making changes appropriate to the findings from inspection. Examples of practices 
facilitating (inspection and) adaptation are the sprint planning, daily scrum, sprint retrospective, and sprint 
review meetings. 


Think about it. How often do team members change in your organization? The concept of a dedicated team 
© allows team members to stay together for the long term, learning to work together well and become very 
d productive. Can you see how this would increase the speed at which a team could get work done? 


Daily Scrum 

The team’s daily scrum is designed to be short, informative, and to keep work moving forward while wasting no time. This 
meeting is also called the daily standup meeting. All projects can benefit from this type of meeting, at which team members 
are asked and then answer three questions: 


+ What have 1 completed since the last meeting? 
+ What am 1 working on today? 


+ Are there any impediments to progress? 
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Rules for this meeting are: 

+ Ifyou have something to report you must attend. 

+ Ifyou have nothing to report, you shouldn’t speak at the meeting. 
e Talk is restricted to addressing the three questions. 


+ If you have identified an impediment, it will be taken up after the meeting by the Scrum Master (or anyone else who 
may be able to help remove the impediment). It is not to be elaborated during the meeting. 


XP (extreme Programming) 


XP or eXtreme Programming was one of the early agile (software development) methodologies to gain popularity. From 
XP we get these terms, already used in this book: user stories, release planning, iteration, product increment, release, along 
with the concept of small releases. 


XP and Similar Terminology 
XP uses the term “coach” as we have used “team lead” or “agile coach” in this book. The role is analogous to Scrum Master. 
Other XP team members are programmers and testers. XP uses the term “customer” the way that Scrum uses “product 
owner.” 
We also get the terms spike and architectural spike from XP. 
e Spike Also known as a “risk spike,” this is an iteration specifically planned to explore risks to understand them better 
and thus reduce them. Unlike other iterations, a product increment is not produced. 
e Architectural spike Like a risk spike, this type of iteration doesn’t require that a product increment be delivered at 
the end. Architectural spikes explore new technological approaches to show they will work for the product and 
the project. 


XP has activities, values, and practices. 


XP Values 
The following values are meant to guide XP teams. The concepts have been integrated into generic agile. 

1. Simplicity This means not adding unnecessary design or functional features, keeping complexity at a minimum. 
Associate “find the simplest thing that could possibly work” with XP. 

2. Communication This ensures all team members know what others are working on and also understand the 
big picture. 

3. Feedback “Fast failure” is a commonly used agile cliche that comes from XP. Delivering prototypes and other 
possible solutions fast means the team finds out quickly what works and what is pleasing to the customer. 

4. Courage XP encourages collaboration through practices where people work closely together and remain 
transparent about their work. See for example, pair programming and collective code ownership in the XP Practices 
section. 

5. Respect This should be self-explanatory in any team environment where everyone is collectively responsible for 
results, are experts in their field, and yet are working on something new on a daily basis. Teamwork cannot work 
without mutual respect. 
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XP Practices 
As a programming methodology, XP is mainly concerned with software engineering practices. Thirteen core practices 


underlie the XP methodology. 


$. 


W: 


12: 


Whole team This is the agile concept that the team has all skills needed to build the product and that team works 
together on the project. This is similar to the SCRUM concepts of dedicated and cross-functional teams. 


. Planning games Release planning and iteration planning are called planning games. 


Small releases Like other agile methodologies, small releases allow XP teams to deliver small sets of prioritized 
features frequently, thus providing a continuous delivery of value. 
Simple design Keeping the design as simple as possible helps enable frequent small releases and provides a more 
easily maintained product in the long run. 


. Metaphor XP practitioners use metaphors and analogies to make technical concepts understandable to customers. 


Sustainable pace This is the same as saying that having the team do overtime to make a deadline is not a viable 
scheduling strategy on projects. Product developers should be able to work at a pace that is sustainable in the 


long term. 


Customer tests These are tests driven by customer descriptions of how the software should behave to indicate 
that it is working as intended. 
Example “When I click the ‘Menu’ option, options X, Y, and Z should appear.” 


Test-driven development This means the team creates the tests before they develop the code (or product 
increment). The code has to be built to pass the tests. 


Pair programming This is the practice of two developers working together, taking turns developing code while 
the other watches. It increases quality because “another set of eyes” on the product as it is being developed is better 
than the active developer working alone. 


Collective code ownership No one on the team owns the product; the team as a whole owns the product. This 
means that any programmer pair can change code when they find they can improve it, regardless of who originated 
the code. 


Code standards XP teams follow a stringent coding standard. This keeps pair programming and collective code 
ownership from resulting in a product with an inconsistent design. 


Continuous integration How do you know that when a new product increment is created it won’t break the 
product? Continuous integration means integrating all new code into the product (once unit testing is done) on a 
regular basis to ensure the product continues to work as planned, as new code is added. 


Refactoring There is always more than one way to accomplish something. As a product is built, more and less 
efficient components can wind up as a part of it. Think of refactoring as doing cleanup. Refactoring is not changing 
the way the product works but making the code more efficient by removing duplicate or unnecessary code and 
implementing design simplification and other improvements. 

Example Imagine the software development team who built your favorite mobile app. They had an idea and 
worked together to build features they hoped you would like. The first release of the app was probably small and 
simple, with just a few features. They received feedback and continued to add more features based on customer 
responses. Some new releases are fixing problems (refactoring) and every change is integrated with the existing app 
(continuous integration). 
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Crystal Family of Methodologies 


Crystal is a group of methods that the project manager and team tailor to find a situation-specific solution. For the exam, 
you are most likely to see questions that link Crystal with tailoring. Figure 17.2 looks complicated, but we provide it just to 
show you that with Crystal methodologies, you choose a specific set of practices based on the criticality of the project. 


The colors are just names for different approaches. Of course, larger teams require more structure and governance. 


Criticality categorizes projects by their potential risks and impacts. For example, a “C6” project has a low level of criticality, 
so practices can be relatively lightweight. By contrast, the other extreme is Magenta (L200), a set of practices for any 
project with a risk to Life (L), like building a medical device, regardless of team size. A criticality of “Life” indicates the 


most formal and stringent use of processes and methods. 


Clear Yellow Orange Red Magenta 


Criticality 
Lz/e (L) 
Essential 
money (E) 
Discretionary 
money (D) 


Comfort (©) | C6 
1-6 


L6 


E6 


7-20 21-40 41-80 81-200 


Team Size 


FIGURE 17.2 Crystal methodology considerations based on criticality 


DSDM 


Dynamic Systems Development Method (DSDM) is an early agile method that still has influence within generic agile. As 
a stand-alone method it is more prevalent in the UK. We display the DSDM eight core principles’ life cycle alongside figure 
17.3, just to help you be aware of it and give you an idea of its similarities to other agile methods that influence agile. 


DSDM Core Principles 


Focus on business need 

Deliver on time 

Collaborate 

Never compromise quality 

Build incrementally 

Develop iteratively 

Communicate continuously and clearly 


Demonstrate control 


mm | 
— 


FIGURE 17.3 DSDM life cycle 
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Scaled Agile Framework® (SAFe®) 


We’ve been talking about small agile teams—self-organizing, cross-functional groups of people who work together to build 
a product. These small teams work well for building a mobile app or a video game. But how would a small team build a large 
system like an enterprise management system or inventory control system? And how would a portfolio or program be 
managed using agile practices? “Scaled agile" refers to using the agile mindset in a larger context. 

The Scaled Agile Framework’, first released in 2011, is a set of management practices and processes that guide a 
group of agile teams to work towards a common, often longer-term, goal. This framework uses small agile teams, working 
in concert with each other, each producing a part of a larger product or solution. SAFe promotes alignment, collaboration, 
and delivery across a large number of agile teams. SAFE is based on three of the bodies of knowledge you have been 
learning: agile development, lean product development, and systems thinking. 

In SAFe, agile teams may use Scrum or another agile approach at the team level. Their work is coordinated under the 
SAFe Framework. A “team of teams” oversees the work of the individual teams (usually 5-12 teams) and is called the Agile 
Release Train (ART). SAFe also has unique roles like the Release Train Engineer (RTE). 


Think About It. SAFe uses a train analogy, with each train car being an agile team. Train cars each have a specific 
purpose: some carry grain, some are refrigerated to carry food that would spoil in heat, some carry vehicles, and 
they can link together with any other car because they are all the same size and have the same connection 
mechanism. In an enterprise using the SAFe framework, each team is assigned a specific component or aspect of 
the product to build, and then links it together with other teams who are working on other components of the 
same product. Ideally, work is timed so that all the pieces come together at the same time and the product is 
delivered as scheduled. 


Here are the four core values of SAFe: 


Alignment The alignment value refers to making sure all teams are aligned to organization strategy, goals, and each 
other. When several agile teams are working on the same product it is critical that their work is clearly aligned. 

Built-in quality Built-in quality refers to the importance of building quality product components and increments of 
the solution. Since components built by different teams will need to “fit together,” they all must be built to the same 
quality standard. The value of built-in quality comes from the lean principle of “build integrity in.” The bigger the 
product, the more important that quality is built in. Without this value, rework and lower velocities are guaranteed. 
Transparency Transparency means openness, honesty, and decision making based on facts. Transparency requires 
trusting relationships between team members and teams. Transparency also refers to the behaviors of making sure 
that everyone involved with the product and project understands the goals and vision. 

Program execution Nothing will be accomplished if teams don’t execute according to the plans and the framework. 
Teams must be well-trained, coached, and understand their role within the entire framework. 


SAFe defines levels of work, each larger and more strategic than the prior. 


Team This is the agile team using Scrum or another agile approach. 


Program As defined in the “Project Management Foundations” chapter, a program is a group of projects that are 
coordinated to support a related organizational goal. 


Essential SAFe The team and program levels are combined into Essential SAFe. 
Large Solution A large, organization-wide solution. 


Portfolio As defined in the “Project Management Foundations” chapter a portfolio includes programs, projects, and 
related operational work supporting a strategic business goal. Most organizations have just a few portfolios. 
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Leadership for SAFe 


Leadership is important for success with the SAFe framework. Roles like the portfolio managers and product managers all 
have specific responsibilities for their part of the framework. They are responsible for prioritizing work, communicating 
about stakeholder needs, reviewing completed work, and providing feedback to the development teams. It requires strong, 
clear leadership to make sure that each train car gets linked to other cars going to the same place, gets on the right tracks, 
avoids collisions with other trains, and delivers as promised. Be prepared to answer exam questions about scaling agile for 
large solutions using SAFe. 


Feature Driven Development (FDD) 


Feature Driven Development (FDD) also originated from software engineering. In looking at figure 17.4, can you see the 
similarities between FDD and agile practices you have learned about in this book? FDD is focused on feature delivery, 
starting from an overall model. Then, the feature list (analogous to a backlog) contains client-valued increments of func- 
tionality from the high-level model. The product is then planned by feature and work from there moves into designing and 
building. 

Feature-Driven Development is the agile methodology that popularized cumulative flow diagrams and parking lot 
diagrams, which are one-page summaries of project progress. Both are useful tracking and diagnostic tools that are now 
used by other agile approaches. 


Design by 


Build by feature 


feature 


FIGURE 17.4 FDD or feature driven development 


Agile Values and Principles 


A group of software development professionals wrote agile’s four values and twelve principles called the Agile Manifesto. 
It is not necessary to memorize this for the exam, but as you read the Agile Manifesto it should make good sense to you 
considering what you know about how agile works as a tailored set of practices. 


We suggest you substitute “product" or “service" for “software,” depending on your profession. 


Agile Values 

As you look over these four values, you will recognize that the items on the right are directly related to a plan-driven 
project. The bolded items on the left are at the core of agile projects. The manifesto states that “while there is value in the 
items on the right, we value the items on the left more.” 


Individuals and interactions over processes and tools 
Working software over comprehensive documentation 
Customer collaboration over contract negotiation 


Responding to change over following a plan 


The format of the four values—A over B (“Individuals and interactions over processes and tools”)—addresses 
intention, focus, and effort. This isn’t as black and white as just saying, “Do A instead of B.” Instead, it acknowledges that 
both A and B will be components of projects, but that we should apply more of our focus, emphasis, and intention to A 
than to B. 
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Agile Principles 
In addition to the four agile values, the authors of the Manifesto (Agilemanifesto.org) created twelve guiding principles for 
agile methods: 
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 
2. Welcoming changing requirements, even late in development. Agile processes harness change for the customer s 
competitive advantage. 
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the 
shorter timescale. 
4. Business people and developers must work together daily throughout the project. 
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to 
get the job done. 
6. The most efficient and effective method of conveying information to and within a development team is face-to- 
face conversation. 
7. Working software is the primary measure of progress. 
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain 
a constant pace indefinitely. 
9. Continuous attention to technical excellence and good design enhances agility. 
10. Simplicity—the art of maximizing the amount of work not done—is essential. 
11. The best architectures, requirements, and designs emerge from self-organizing teams. 


12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its 
behavior accordingly. 


17.1 Exercise 
Think about these principles. In your own words, describe what each principle means to you. Can you see how 
some of these might apply to your projects? 


Principle What does this mean to you? 


Our highest priority is to satisfy the customer through 
early and continuous delivery of valuable software. 


Welcome changing requirements, even late in 
development. Agile processes harness change for the 
customer s competitive advantage. 


Deliver working software frequently, from a couple of 
weeks to a couple of months, with a preference to the 
shorter timescale. 


Business people and developers work together daily 
throughout the project. 


Build projects around motivated individuals. Give them 
the environment and support they need and trust them 
to get the job done. 


The most efficient and effective method of conveying 
information to and within a development team is 
face-to-face conversation. 


Working software is the primary measure of progress. 
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Agile processes promote sustainable development. The 
sponsors, developers, and users should be able to 
maintain a constant pace indefinitely. 


Continuous attention to technical excellence and good 
design enhances agility. 


Simplicity—the art of maximizing the amount of work 
not done—is essential. 


The best architectures, requirements, and designs 
emerge from self-organizing teams. 


At regular intervals, the team reflects on how to become 
more effective, then tunes and adjusts its behavior 
accordingly. 


The Agile Mindset 
ER e oa e l 


You may see the phrase Agile Mindset on the exam. This phrase refers to the idea that you don’t just memorize the values 
and principles and join an agile team. To be agile, you must change your thinking to adopt these principles and ways of 
working. It takes time to learn and adopt an agile mindset and it will change the way you view much of your work. Agile 
approaches are less prescriptive than plan-based approaches and rely more on the team members operating with an agile 
mindset. 


Key Concepts 


Here are a few concepts, derived from the values and principles, that you may see on the exam. 


Welcoming Change 


A major difference between predictive and adaptive environments is the project managers (and teams) response to 
customer requests for change. In plan-driven life cycles, changes are considered “necessary evils” requiring a process— 
Integrated Change Control—to include the change into a project that is already underway. Agile approaches welcome 
change. When you see exam questions about changes to the project, be sure to notice if the project manager is using a 
plan-driven or agile approach before you answer. 


Working in Small Value-added Increments 
Exam questions about plan-driven projects assume large projects with hundreds of stakeholders and long timelines. Exam 
questions about agile projects refer to smaller teams, building small increments of a product, delivered to customers as 
soon as possible. This is not to say that large projects would not use an agile approach, but remember that products are built 


in small, valuable increments that can be delivered to the customer faster than the entire product. 


Using Build and Feedback Loops 
Customers or their representatives (e.g., product owners) are closely involved with agile teams and give frequent feedback. 
At the end of every iteration customers are shown demonstrations of the product component most recently built, and they 
can request any changes they want. These frequent feedback loops prevent the team from going too far down a path that 


the customer would not like. 


Learning through Discovery 

Experimentation or discovery is important for new, innovative products to emerge. As new technologies become available, 
teams may need time to learn how best to use them. Agile teams recognize the need to plan time for learning and 
experimentation. Prototypes are often built early in the project to test out ideas. This ties into the prior principle of build 
and feedback loops. Prototypes are viewed by customers who provide early feedback. Once the team has successfully 


tested a new technology, product development progresses more smoothly. 42 0 
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Failing Fast with Learning 

Related to learning through discovery, the concept of fast failure results in additional learning. Agile methods recognize 
that some experiments fail and the team should find out as soon as possible if a new technology or architecture is going to 
work. If not, they can stop and redesign. Human nature often leads teams to do the easy work first, putting off the hard tasks 
until the end. But, finding out that new technology won’t support the new product at the end of the project can be 
devastating and will have wasted many hours of time. 


Value-driven Development 

Agile leaders and their teams are always focused on providing value to their customers. Analysis of existing software 
products reveals that 80% of many application features are rarely used (remember the Pareto 80-20 rule?). Organizations 
have realized they need to focus on the most valuable product features first, delivering to the customer as early as possible. 


Continuous Delivery 

Another important concept of agile approaches is continuous delivery. When possible, teams build products in increments 
and deliver them as soon as they are usable for the customer. Think about your mobile phone updates. Your phone provider 
is continuously delivering new features, updates to existing features, corrections and enhancements to your phones 
operating system. They are creating a minimally viable product. 


Continuous Improvement 
Finally, the concept of continuous improvement is used throughout project execution. Continuous improvement processes 
and techniques have been around for a long time. Agile approaches build on existing tools like Lean and Kanban to 


encourage continuous improvement. Plan-driven project life cycles use lessons learned to improve future projects. Agile 
life cycles use retrospectives. Regardless of the approach used, all teams should be constantly learning and finding better 
ways of working. 


The Agile Triangle 

In project management, understanding the project constraints is one of the most important tasks of the project manager. 
In traditional, plan-driven life cycle approaches the scope is considered a key constraint. Once the scope is approved by the 
customer, changes to the scope are discouraged because the entire project management plan is built around accomplishing 
the agreed-upon scope. The cost and time constraints of the project are impacted if scope is changed. 


In agile life cycle approaches, these constraints are turned upside down. (The inverted triangle model was first 
published in the DSDM Manual in 1994.) As you can see in figure 17.5, agile approaches start with the time and cost 
constraints, agreed upon by the customer or sponsor and the scope is allowed to change during the project. There are 
several benefits to this approach. One is the sponsor or customer knows the labor cost at the beginning of the project. 
Rather than just an estimate, the labor cost agreed to will be the actual amount of money to be spent because the agile team 
has a fixed number of members and fixed amount of time. For example, if a project manager has asked for 5 team members 
for 3 months, the actual cost of the team is known at the beginning of the project. 

Another customer benefit of an agile approach is the flexibility to change the desired scope as the project moves 
along. The product is built in small increments and the customer reviews and approves each increment. After seeing an 
early version of the product, the customer may choose to move the product in a different design direction than was 
originally planned, with no negative impact to the time or cost. Imagine a project to publish a digital book where each 
chapter is released online as it is completed. As chapters become available to readers, they can provide feedback, and 
revisions to these early chapters can be made at any time. Later chapters will build on the early chapters incorporating in 
feedback (e.g., “more illustrations please”) increasing the quality and usefulness of the entire book. 
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An advantage of the inverted triangle, to the agile team, is they don’t spend hours trying to document every detailed 
requirement in a document and/or spend hours trying to estimate the time it will take to build the product. Many project 
teams struggle with both requirements and estimating complex knowledge products, so an agile approach decreases time 
spent doing things that humans are not very good at anyway. 


Traditional Agile 
Triangle of Constraints Triangle of Constraints 
Scope Cost Time 
t fixed — 


qee Variable mnh 
Time Cost Scope 


FIGURE 17.5 Inverted triangle model 


17.2 Exercise 


e- Think about it. As you approach your next project, will you consider an agile approach? What would be the 
an reasons you should consider one? Write your answer in your Exercise Notebook. 


Answer 


Here are some examples of what you might have come up with. You may have come up with some other ideas 
as well. 


+ New unique or complex knowledge product 

+ The sponsor is looking for cost savings in a complex process 

* Unclear scope or unknown requirements 

+ The product could be delivered in increments 

+ The product will use a new, untried technology 

+ Early delivery of value to a market would generate early revenue or beat a competitor to market 
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Principles and Domains 


Introduction 


After reading this book you will have already learned a great deal of what you need to know for the exam 
from the PMBOK* * Guide, Seventh Edition. We weaved PMBOK* Guide information into the content of 
this book although we have not always identified it specifically as PMBOK* Guide content. It was 
enough for you to concentrate until now on the Examination Content Outline (ECO), the Process 
Groups model, and the spectrum of project management approaches including agile, plan-driven, and 
hybrid approaches. 

Now it is time to fill in a few gaps so you have a more comprehensive understanding of how the 
content of the exam and the PMI publications fit together. 


Think About It. Before you continue reading this chapter you should review the concepts 
~  you’ve been learning. Think about how all the pieces fit together as you review the following 
> 4 sections of the “PMP* Exam References in Context” chapter: 


+ Examination Content Outline (ECO) Overview. 

* The Process Groups Model Overview. 

e Rita’s Process Chart'" Game You should have played this game once when you first 
read that chapter. Now that you have read more about predictive project management 
processes in this book, it is a good time to play this game again for review. 

e  Rita’s Agile Process Chart” Game You may want to practice playing this game again 
for review. 


Reviewing this information will prime your memory so you are more comfortable with these 
concepts as we now pull in the additional information from PMI’s PMBOK* Guide and The Standard 
for Project Management. 

As you read about the PMBOK* Guides performance domains in the next section of this chapter, 
we will point out parallels between these performance domain concepts and the ECO and Process 
Groups model to which you were already introduced. 

To start, know that the PMBOK* Guide is neither process-based nor prescriptive. It is based on 
performance domains. A performance domain is a group of related activities that interact and are 
interdependent. Keep in mind that while it is useful to group critical project management activities 
together into distinct domains, project management needs to be looked at holistically. 


The PMBOK® Guide, the ECO, and Process Groups | 


In each of the ECO Process (domain II) chapters we mapped three sets of concepts: 
+ ECO tasks most applicable to the content of that chapter 
* Process Groups model processes applicable and most closely aligned to the content of the chapter 


+ PMBOK* Guide performance domains most closely associated with the ECO tasks and Process 
Groups model processes we identified for that chapter 
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In this chapter, we look at these charts again with attention to the PMBOK* Guide domains. The concepts are not new 
so you will easily be able to relate them to what you already know about the ECO processes, the Process Groups model 
processes, and agile and hybrid methods. The PMBOK* Guide's performance domains will no doubt sound familiar because 
the PMBOK* Guide is looking at the same concepts through a different lens. 


The PMBOK* Guide's performance domains are as follows: 


* Stakeholders * Project Work 
* Team * Delivery 

+ Development Approach and Life Cycle * Measurement 
+ Planning e Uncertainty 


We will ask you to look at these performance domains and think about the following figure from the standpoint of 
integration management. Integration management is related to and affects all these performance domains. 


Domain II Integration Management 
Task 1 Domain 2.1 
Execute project with the urgency required to Develop Project Charter — Initiating Stakeholders 
deliver business value £ 
Develop Project Management Plan — Planning Domain 2.2 
Task 9 Team 
Integrate project planning activities Direct and Manage Project Work $ 
[L þeours Domain 2.3 
Task 10 Manage Project Knowledge Development Approach and Life Cycle 
Manage project changes ; 
Monitor and Control Project Work —> Monitoring Domain 2.4 
Task 12 Planning 
Manage project artifacts Perform Integrated Change Control — ë Controlling i 
Domain 2.5 
Task 13 Close Project or Phase —— Closing Project Work 
Determine appropriate project 
P Domain 2.6 
methodology/methods and practices 3 
Delivery 
Task 16 p 
Ensure knowledge transfer for project continuity Bomania 
Measurement 
Task 17 ‘ 
Plan and manage project/phase closure BEEN 
or transitions Uncertainty 


FIGURE 18.1 Mapping of integration management 


With integration management, the project manager is creating a cohesive, holistic system of organization for just 
about everything they, the team, and other stakeholders do on a project. This is to ensure that all project stakeholders have 
a common understanding, the project proceeds in an orderly and predictable manner, and the organization and its 
stakeholders receive the desired requirements and outcomes for which the project was undertaken. High performance is 
required of the project manager and the team in all the PMBOK* Guide ’s performance domains. 


With that in mind, let’s look at each of the PMBOK* Guide performance domains. 


Stakeholders 

This domain is about doing the work needed to ensure the desired stakeholder outcomes during and as a result of the 
project and its deliverables. These outcomes include good and productive working relationships and communications with 
all stakeholders on the project, and a common understanding about and agreement with the project’s goals and objectives. 
These outcomes help ensure customer satisfaction with the project and its deliverables. Another desired outcome of high 
performance in this domain is that opposition to the project does not lead to negative impacts on the project or its 
stakeholders. 


oe Think about it. Can you see how this domain relates to the associated ECO tasks and Process Groups model 
(e integration processes in the integration figure (figure 18.1)? 
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Team 

We discussed high-performing teams in the People domain section of this book. High-performing teams can be achieved 
and maintained not only with skilled and motivated people but with good servant leadership. High-performing teams will 
take shared organization and ownership of their work. Team members will apply emotional intelligence, leadership, and 
other interpersonal and team skills in relationships and work on the project. 


Think about it. Can you see how this domain relates to the associated ECO tasks and Process Groups model 
a) integration processes in figure 18.1? Can you see how all these tasks and processes depend upon team performance ? 


a 
Development Approach and Life Cycle 
High performance in this domain can achieve the desired outcomes of using a development approach and life cycle for 
each project that is consistent with organizational governance but also tailored to the specific characteristics and needs of 
each project. 

A properly selected and executed development approach and life cycle will also result in using phases (and/or 
iterations) to deliver the desired business value to project stakeholders at a pace consistent with the needs of the project, 
the building of its deliverables, and the maintenance of the project’s benefits beyond project closing. 


ce Think about it. Can you see how this domain relates to the associated ECO tasks and Process Groups model 

processes in the integration figure (figure 18.1)? The development approach and project life cycle is carefully 

@ selected at the beginning of planning (or earlier in initiating) and is carefully tailored throughout the project in 
accordance with the project’s needs. 


Planning 
How can you have a successful project without planning? You can’t. Planning, of course, is related to all ECO process 
domain tasks and depends on good outcomes from the ECO People and Business Environment domain tasks. Project 
planning (and this performance domain) is about achieving the following desired outcomes: 
* Planning is tailored to the needs of the project so that stakeholder engagement and each phase, iteration, and 
deliverable are planned with rigor but just enough detail, and no more than is needed. 
+ The project progresses in an orderly fashion with few or no risks that have not been accounted for with risk response 
plans in the backlog (or WBS) and schedule, and contingency reserves in the budget. 
+ As new information becomes available, iterative planning and progressive elaboration on project management plans 
continue to evolve, as well as work and measurement strategies, to achieve the defined project outcomes. 


oo Think about it. Can you see how this domain relates to the associated ECO tasks and Process Groups model 


& processes in the integration figure (figure 18.1)? This performance domain summarizes why planning is so 
yy important to every aspect of project management and product delivery to stakeholders. 
Project Work 


Just as the executing process group dovetails with the planning process group, the Planning and Project Work performance 
domains come together. The desired outcomes from this domain are efficient and effective project performance from all 
involved stakeholders, not least of which are the project manager and team. 

Good project management work means the following produce results appropriate to the needs of the project and 
ongoing process improvements for the organization: 


* Project processes + Stakeholder engagement and communications 
+ Effective management of physical resources + Continuous improvement and learning for the team 
and procurements and processes 
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Think about it. Review the integration figure (figure 18.1). Can you see how this domain relates to the 
associated ECO tasks and Process Groups model processes in the figure? Think ahead about how the work and 
E outcomes of this Project Work domain will also dovetail with those of the Delivery and Measurement domains. 


Delivery 
This domain is about delivering the scope for which the project was undertaken, at the appropriate quality according to 
product and quality requirements. Remember the connections of the scope and quality processes: 


* The measurement (or monitoring and controlling) process of Control Quality while the team is building a deliverable 
leads to... 


* The ability of the team and project manager to present the deliverable to the stakeholders (or customer) for acceptance. 
This process is called Validate Scope. 


Successfully carrying out planning, project work (along with doing measurement along the way) leads to the desired 
outcomes of delivery. The project manager and team’s understanding of and ability to execute against a clear understanding 
of project requirements should lead to the following desired outcomes. They are the achievement of: 


+ Projects goals and objectives + The project’s completion on schedule 
* The project’s contribution to the organizations * + Stakeholder’s acceptance of and satisfaction with 
business goals and objectives (tied to advancement project deliverables 


of its business strategy) 


Think about it. Review the integration figure (figure 18.1). Think holistically about the domains discussed so 
far and their associated ECO tasks and project management processes. Doing so should give you a comfortable 
overview of project processes and the people skills that support them. You should understand that knowledge of 
and interaction with the business environment ensures that projects are governed appropriately and to the 
benefit of the organization and its stakeholders. If you are not comfortable yet with how all these concepts come 
together, that just means you need more time reviewing this book and its interactions and exercises. 


Let’s now look at the final two PMBOK* Guide performance domains. 


Measurement 
Remember the Monitoring and Controlling process group within the Process Groups model? Measurement is about 
monitoring and controlling; observing and measuring from when the project starts until it is completed. Measurement’s 
purpose is to be able to see when changes need to be made to improve project performance. Measurement outcomes 
include being able to take the data observed about the project and create reliable forecasts throughout the project life cycle. 
The outcomes from measurement should be continual and there should be a common understanding of the project’s status 
among all stakeholders. This outcome should in turn lead to timely changes within the project as needed to keep project 
performance on track and achieve the planned targets and business value. 


Uncertainty 

PMI defines uncertainty as a lack of understanding or awareness of issues, events, paths to follow, or solutions to pursue. 
Uncertainty results from a combination of risk, ambiguity, complexity, and volatility. Let’s look at these concepts, a 
combination of which helps explain why uncertainty warrants a performance domain of its own: 


e Ambiguity is when events, conditions, and their causes could have more than one interpretation and choice 
of solution. 


* Complexity means having many related and interdependent factors that need to be considered simultaneously. 
Ambiguity contributes to complexity and with complexity there often seems to be contradictory facts or conditions 
that are true at the same time. These seemingly contradictory factors or conditions cannot be reconciled so instead the 
best choice needs to be made even though all information may not be available with which to make it. 


e Risks are uncertain events that may or may not happen on the project. They exist in two basic forms: threats and 
opportunities. Threats will cause problems with achieving the balance of project constraints if they occur while 
opportunities may allow us to achieve project objectives with even better performance than planned. 


446 


EIGHTEEN 


While PM I teases out these various meanings and summarizes them as uncertainty, what we know without all this is 
that projects are about achieving things for organizations and their stakeholders that have never been done before, under 
conditions for which all the information cannot be available for the precise reason that it has never been done before. 

Outcomes of successfully navigating uncertainty include an awareness and a comfort with one’s ability to manage an 
uncertain environment and complex projects that carry risks. Being able to proactively manage uncertainty means the 
capacity to plan, measure, and control the project while anticipating and planning for risks so that threats deliver little or 
no negative impact on project goals and objectives. We also can add to this that navigating uncertainty successfully means 
achieving the outcome of delivering the value for which the project was undertaken on schedule, within budget, and at the 
appropriate level of quality. In this way projects also contribute to the organization’s long-term business objectives. 


Mapping the PMBOK® Guide to the ECO and Process Groups Processes 


The integration management responsibilities of the project manager were a perfect fit for discussing the PMBOK* Guide's 
domains because integration is all-encompassing. Now, spending additional time reviewing the remainder of the ECO 
Process (domain II) tasks and their associated processes through the lens of PMBOK* Guide domains will help you contin- 
ue to review this material. 


Cee Think about it. We have reproduced all the figures from the Process domain chapters here, for your convenience. 

For each one, we have given you key phrases to help stimulate your thinking. Study them now to review the ECO 
tasks alongside the Process Groups model processes, but most importantly, relate them to the PMBOK* Guide 
performance domains listed. 


Process Groups Model PMBOK® Guide 


Domain II Scope Management Domain 2.4 
Planning 
Task 8 Plan Scope Management Domain 2.6 
Pi A 
lan and manage scope Collect Require! ue Delivery 
Scope ang Domain 2.7 
ai Measurement 
Create WBS Domain 2.8 
Validate Scope Monitoring Uncertainty 
Control Scope E & Controlling 


Scope: Planned, measured, delivered through uncertainty, tailoring 


Process Groups Model PMBOK® Guide 


PMBOK® Guide and the PM Standard 


Domain II Schedule Management Domain 2.4 
Planning 

Task 6 Plan Schedule Management —: Domain 2.7 

Plan and Manage Schedule 
Define Activities Measurement 
Blanhing) Domain 2.8 
Sequence Activities Uncertainty 
Estimate Activity Durations 


Develop Schedule — 


Control Schedule — 


Monitoring 
& Controlling 


Schedule: Planning and executing the proper timeline through uncertainty, tailoring 
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Domain II Cost Management 


Task 5 Plan Cost Management — 


Plan and manage budget and resources k 
Estimate Costs Planning 
Determine Budget — 


Control Costs —| Monitoring 
Control Resources —> » Controlling 


Domain 2.4 
Planning 


Domain 2.6 
Delivery 


Domain 2.7 
Measurement 


Domain 2.8 
Uncertainty 


Cost: Staying within planned and agreed spending parameters through uncertainty, tailoring 


Domain II Quality Management 
Task 7 Plan Quality Management — Planning 


Plan and manage quality of products/deliverables 
Manage Quality — Executing 


Control Quality — Monitoring 
& Controlling 


Domain 2.4 
Planning 


Domain 2.6 
Delivery 
Domain 2.7 
Measurement 


Domain 2.8 
Uncertainty 


Quality: Scope, schedule, and cost managed to requirements through uncertainty, tailoring 


Domain | 
Task 1 
Manage conflict 


Task 2 . ivity R 
Lead a team ol Iai) jr 


Task 4 


Resource Management 


Plan Resource Management 
a Planning 


Domain 2.2 
Team 


Domain 2.4 
Planning 


Domain 2.5 
Project work 


Domain 2.6 


Empower team members and stakeholders 


Task 5 


Task 3 a inna 
Support team performance Develop Team | Executing 


Manage Team 


~GentretReseurees- — -Menitering— 
~&-Gentrotting- 


Delivery 


Domain 2.7 
Measurement 


Ensure team members/stakeholders are adequately trained 
Task 6 

Build a team 

Task 7 

Address and remove impediments, obstacles, and blockers for the team 
Task 8 

Negotiate project agreements 

Task 9 

Collaborate with stakeholders 

Task 10 

Build shared understanding 

Task 11 

Engage and support virtual teams 

Task 12 

Define team ground rules 

Task 13 

Mentor relevant stakeholders 

Task 14 

Promote performance through emotional intelligence 


Resources: Servant leadership requires all People domain skills; tailoring 
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Domain II Communications Management Domain 2.1 
Stakeholder 
Task 2 Plan Communications Management — Planning Domain 2.2 
Manage communications i 
Manage Communications — Executing Team 
Monitor Communications — Monitoring Domein ae 
& Controlling Planning 
Domain 2.5 
Project work 
Domain 2.8 
Uncertainty 


Communications: Closely tied to all good stakeholder relationships; tailoring 


Domain | Risk Management Domain 2.7 
Task 7 Measurement 
Address and remove impediments, Plan Risk Management — Di in28 
obstacles, and blockers for the team are 3 
Identify Risks Uncertainty 
Domain II Perform Qualitative Risk Analysis Planning 
Task 3 
Assess and manage risks Perform Quantitative Risk Analysis 
Task 15 Plan Risk Responses — 
M ject i 
anadelprolecriecuce Implement Risk Responses — Executing 
Monitor Risks — Monitoring 
& Controlling 


Risk: Embodiment of uncertainty; plan, navigate, measure, tailor 


Domain | Procurement Management Domain 2.4 
Task 8 Planning 
Negotiate project agreements Plan Procurement Management — Planning Domain 2.5 


Conduct Procurements — Executing Project work 


Domain II r 
Task 8 Control Procurements — Monitoring Domain 2.7 
a & Controlling Measurement 
Plan and manage scope 
Domain 2.8 
eae Uncertainty 


Plan and manage procurement 


Procurement: Achieve part of scope through partners; plan, execute, measure through uncertainty 
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ECO Process Groups Model PMBOK® Guide 


Domain | Stakeholder Management Domain 2.1 
Task 4 Stakeholder 
Empower team members and stakeholders Identify Stakeholders — Initiating Domain 2.4 
Task 9 Plan Stakeholder Engagement — Planning Planning 

ll i hi 
Collaborate with stakeholders Manege ider Engagement — Executing Domain 2.7 
Task 10 ; i Measurement 
Build shared understanding Monitor Stakeholder Engagement — Monitoring Domain 2.8 
& Controlling 

Task 13 Uncertainty 
Mentor relevant stakeholders 

Domain II 
Task 4 
Engage stakeholders 


Stakeholders: For whom we do it all; tied to communications; 


The Standard and the PMBOK® Guide 


tailor through uncertainty 


PMI’s The Standard for Project Management (Standard) and the PMBOK* Guide complement each other and they both 
speak to the same purposes and outcomes. But the PMBOK* Guide is organized into performance domains, while the Stan- 


dard is principle-based. 


Both the PMBOK* Guide and the Standard speak of projects as a system for value delivery, a concept discussed earlier 
in this book that has run through all our discussions of project management. The purpose of the Standard is to provide an 
understanding of how project management enables intended outcomes. The principles in the Standard then, enable the 


successful achievement within the performance domains. 


First, the most basic principles outlined in the Standard are responsibility, respect, fairness, and honesty, in keeping 
with the original principles underpinning the PMI Code of Ethics and Professional Conduct. You should spend a bit of 
time observing Figure 18.2, which illustrates the Standards principles alongside the PMBOK* Guide's performance 
domains. As you study this figure, keep in mind that the principles of the standard support and enable the domains and 


outcomes described in the PMBOK* Guide. 
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Principles 


Domains 


FIGURE 18.2 The Standard's Principles support the PMBOK" Guide’s Performance Domains 
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Conclusion 


You have reached the end of this book! Congratulations! 

As noted in chapter 1, we recommend that you review the information in this book several times to really retain what 
you learned. So read through this book again, focusing on the areas where you have identified gaps in your knowledge. In 
a second pass through this book you will find that you understand some topics differently than you did the first time, and 
other concepts will stand out to you that you previously missed. 

Make sure you utilize the tools we have provided to help you pass the exam. Revisit the 
Quicktests at the beginning of each chapter to make sure you know each of the items presented. If you 
don’t know something, note it as a gap and revisit that section to familiarize yourself with that topic. 
Play the Rita’s Process Chart™ and Rita’s Agile Process Chart™ games on our RMC Resources page. 
Go back to any exercises you struggled with and try them again. And, utilize the RMC Interactive 
Chapter Quizzes to gain experience answering questions similar to the ones you’ll find on the exam. 


Having a solid understanding of the project management process and the material presented in 
this book will not only help you pass the exam (you can use logic instead of having to memorize 
information), it will also enable you to apply what you have learned to your real-world projects. 


RMC RESOURCES 


Thank you for taking this journey with us. We hope you will come back to RMC Learning Solutions after you have 
earned your PMP. We can help you continue your training and earn PDUs to maintain your certification through our 
advanced instructor-led and eLearning courses and products. So good luck, and we look forward to seeing you after you 
pass the exam! 
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